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FOREWORD 


Clearly,  the  focus  of  U.S.  military  training  has  become  joint  warfighting.  Just  as  clearly,  planning 
and  operating  with  armed  forces  of  different  services  and  philosophies  will  introduce  Joint  Force 
Commanders  and  staffs  to  situations  they  have  never  seen,  nor  thought  through.  They  must  be 
trained — with  simulations,  wargames,  and  exercises — not  on  the  battlefield.  Exercises  are  expensive 
in  dollars  and  manpower.  Joint  simulations  and  wargames  must  be  granted  priority. 

From  my  perspective  as  a  former  unified  command  Director  for  Operations,  the  Joint  Warfare 
Simulation  Object  Library  approach  is  on  the  mark.  It  offers  a  route  to  consistent  joint  modeling  that 
can  carry  the  warfighter  into  the  next  century. 

B.  G.  Butcher 
Major  General 
U.S.  Marine  Corps  (retired) 
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EXECUTIVE  SUMMARY 


The  Joint  Warfare  Simulation  Object  Library  (JWSOL)  applies  object-oriented  analysis  and  design 
to  modeling  theater-level  joint  operations.  JWSOL  will  be  a  repository  of  reliable,  robust,  reusable 
warfare  simulation  classes  and  objects  that  can  be  used  to: 

•  Develop  and  populate  a  wide  range  of  joint  models  and  scenarios, 

•  Support  interoperation  of  both  new  and  legacy  models  and  simulations. 

PROGRAMMATIC  GOALS 

1 .  Jointness.  JWSOL  will  go  beyond  “multi-service”  interoperability  to  include  true  joint  com¬ 
mand  and  control  (C^)  and  procedural  elements. 

2.  Communication,  cooperation,  and  collaboration.  A  common  library  of  reusable  software 
objects  will  foster  interorganization  communication,  cooperation,  and  collaboration. 

3.  Reuse.  Time-to-field,  reliability  in  the  field,  and  monetary  constraints  all  argue  for  reuse. 
JWSOL  will  support  software  reuse  at  all  levels — conceptual,  analytic,  design,  and  eventually 
code,  documentation,  and  verification  and  validation  (V&V)  test  cases. 

4.  Results.  Recent  changes  in  threat  and  budget  have  focused  the  military  on  the  efficient  use  of 
commercial  products.  JWSOL  will  use  commercial  object-oriented  languages  and  platforms, 
and  comply  with  commercial  standards  for  documentation  and  support  whenever  possible. 

TECHNICAL  GOALS 

Four  near-term  and  six  long-term  technical  goals  for  JWSOL  are  described  below. 


Near-Term 

1 .  Complete  detailed  design;  complete  specification  of  objects.  During  the  second  phase  of  the 
JWSOL  project,  object  specifications  for  the  warfare  objects  defined  in  the  first  phase  will  be 
developed.  These  specifications  will  be  captured  in  an  object  model  developed  and  docu¬ 
mented  with  object-oriented  design  (OOD)  Rumbaugh  software.  The  object  specifications  will 
be  developed  through  an  iterative  process  of  prototyping  and  documenting.  Iterations  will  con¬ 
tinue  until  the  entire  set  of  objects,  with  their  related  inheritance  hierarchies  and  “part  of’  hier¬ 
archies,  come  together  in  a  final  design.  That  design  will  be  documented  iteratively  and  readily 
coded  from  the  specifications.  Subject  matter  experts  (SMEs)  will  continue  to  support  evalua¬ 
tion  during  the  development  of  the  object  specifications. 

2.  Monitor  and  incorporate  evolving  commercial  and  government  standards.  Progress  of  com¬ 
mercial  standards,  such  as  the  Object  Management  Working  Group  (OMWG)  Common  Object 
Request  Broker  Architecture  (CORBA)  will  be  monitored.  Standards  will  be  understood  and 
incorporated  throughout  the  design  and  development  of  JWSOL  objects  to  ensure  compatibil¬ 
ity  with  commercial  object-oriented  products. 

3.  Continue  relationships  with  collaborative  programs.  Coordination  with  collaborative  programs 
will  continue.  Relationships  have  been  established  with  the  Joint  Task  Force— Advanced 
Technology  Demonstration  (JTF-ATD),  OMWG,  Naval  Simulation  System  (NSS),  Joint  Simu¬ 
lation  System  (JSIMS),  Dynamic  Environmental  Effects  Model  (DEEM),  and  Joint  Warrior 
Interoperability  Demonstration-95  (JWID-95)  programs.  Continued  participation  by  JWSOL 
personnel  in  working  groups  associated  with  these  programs  will  provide  the  necessary  feed¬ 
back  to  ensure  the  success  of  JWSOL. 
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4.  Build  prototypes,  deliver  to  programs,  and  perform  beta  test  analysis.  The  third  phase  of 

JWSOL  will  complete  the  prototype  integration  of  commercial  off-the-shelf  (COTS)  and  gov¬ 
ernment  off-the-shelf  (GOTS)  features  and  concentrate  on  the  test  and  evaluation  of  the  library 
features.  Operator  and  user  documentation  will  be  delivered.  The  library  will  be  filled  with 
validated  objects  and  the  first  deployments  will  be  made.  At  the  end  of  this  phase,  the  JWSOL 
capability  will  transition  to  life-cycle  maintenance. 

Long-Term 

1 .  Extend  JWSOL  to  other  warfare  and  operations  other  than  war  areas.  A  natural  customer- 
driven  extension  of  JWSOL  is  to  more  levels  of  operations  and  more  kinds  of  operations.  The 
structure  of  the  taxonomy  is  favorable  to  such  extension. 

2.  Extend  JWSOL  to  multiple  levels  of  resolution.  Multiple  resolution  is  a  difficult  ongoing  prob¬ 
lem  for  modeling  and  simulation  (M&S).  Possibly  using  the  concept  of  perspectives,  JWSOL 
will  be  refined  to  offer  multiple  levels  of  resolution  on  demand.  This  would  apply  to  multiple 
interfaces,  multiple  attributes,  and  multiple  methods,  satisfying  the  levels  of  resolution  neces¬ 
sary,  as  defined  by  customer  demand. 

3.  Integrate  knowledge  systems  technology  into  JWSOL.  Several  available  public-domain  knowl¬ 
edge  systems  tools  might  be  integrated  into  JWSOL;  C  Language  Production  System  (CLIPS), 
Knowledge  Representation  Specification  Language  (KRSL),  and  Knowledge  Acquisition  and 
Design  Structuring  (KADS)  are  three  examples.  Also,  knowledge  visualization  efforts  are 
going  on  in  many  places  in  the  military;  the  Naval  Underwater  Warfare  Center  and  Rome  Lab¬ 
oratory  are  two  research  sites.  Knowledge  systems  tools  and  knowledge  visualization  capabili¬ 
ties  will  be  integrated  to  facilitate  explicit,  user-modifiable  strategy  and  tactics  modeling,  as 
well  as,  deeper  representation  of  C^  decision  making. 

4.  Construct  sample  models  and  applications.  Sample  model  components,  models,  and  applica¬ 
tions  will  be  constructed  using  JWSOL  classes  and  objects.  These  are  valuable  aids  to  pro¬ 
grammers  new  to  JWSOL  in  that  they  provide  guides  to  model  construction.  Use  of  sample 
programs  is  standard  in  commercial  software  tool  publishing. 

5.  Pursue  possible  crossover  with  JTF-ATD  OMWG  C^  Schema.  The  OMWG  Schema  effort, 
discussed  in  section  3.4,  has  been  closely  coordinated  with  the  development  of  the  JWSOL 
Taxonomy.  The  OMWG  C^  Schema  will  evolve  based  on  its  customer’s  needs  and  the  rate  at 
which  it  is  fielded.  JWSOL  covers  areas  that  the  OMWG  is  not  intended  to  support;  but,  for 
common  ground,  the  potential  exists  for  productive  interaction.  Design  and  implementation 
elements  from  OMWG  will  be  incorporated  where  necessary  to  better  support  JWSOL  users. 

6.  Integrate  validated  classes  and  objects  into  an  Information  Analysis  Center  (lAC).  Develop¬ 
ment,  implementation,  documentation,  configuration  management,  verification,  validation,  and 
accreditation  (VV&A),  and  support  activities  will  be  performed  to  make  the  JWSOL  reposi¬ 
tory  suitable  for  incorporation  into  an  I  AC. 

The  analysis  and  taxonomy  presented  in  this  document  will  satisfy  both  near-  and  long-term  goals. 

OVERVIEW 

JWSOL  published  the  JWSOL  Requirements  Document  in  August  1994.  The  taxonomy  described 
in  this  report  is  the  product  of  an  object-oriented  analysis  of  those  requirements. 

JWSOL  sees  the  world  through  the  eyes  of  a  theater  Commander-in-Chief  (CINC).  This  perspec¬ 
tive  was  chosen  because  the  CINC  is  the  center  of  joint  operations,  and  the  challenge  of  analyzing 
truly  “joint”  C^  and  procedures  at  a  level  above  multi-Service  interoperability  rests  at  that  level. 
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The  taxonomy  must  organize  a  large  amount  of  heterogeneous  material,  and  it  is  meant  to  be  a 
general  framework  within  which  even  more  material  can  be  integrated.  The  taxonomy  provides  a 
general  high-level  framework  within  which  greater,  more  refined  decomposition  of  classes  can  occur. 
The  Theater  CINC  and  JTF  Commander  represent  the  theater  strategic  level  of  war,  a  level  at  which 
operations  are  conceived,  planned,  and  coordinated  in  a  truly  joint  context.  The  operational  and  tacti¬ 
cal  levels  of  war,  however,  remain  the  domain  of  the  component  Services.  “Jointness”  at  these  levels 
of  war  is  determined  by  the  adaptability  of  software  objects  for  use  and  reuse  in  varying  resolution  in 
both  joint  and  component  Service  M&S. 

To  illustrate,  at  theater  level,  the  allocation  and  apportionment  of  air  power,  campaign  planning, 
and  development  of  the  air  tasking  order  (ATO)  are  the  main  concerns  of  the  Joint  Force  Air  Compo¬ 
nent  Commander  (JFACC),  the  Air  Operations  Center  (AOC),  and  the  CINC.  To  perform  these  high- 
level  functions,  objects  representing  targets,  aircraft,  munitions,  personnel,  and  airspace  control  mea¬ 
sures  are  not  really  necessary.  Lookup  tables  of  aircraft  readiness  and  other  information  can  provide 
adequate  information  to  the  ATO  plan  object;  however,  to  facilitate  “jointness  in  simulation,”  the 
JWSOL  taxonomy  also  will  include  intervening  component  Service  C^  structures  and  processes,  as 
well  as  specific  combat,  support,  and  logistics  equipment  objects  necessary  to  actually  complete  the 
mission  “thread”  from  ATO  to  time-on-target. 

At  the  top  level,  the  basic  categories  are  Physical,  Event,  and  Agent.  They  are  tied  together  in 
Command  and  Control. 

Physical  includes  military  assets  (ships,  boats,  planes,  satellites,  communications  equipment,  sup¬ 
plies,  etc.),  and  physical  infrastructure  (bases,  railroad  depots,  airfields,  roads,  bridges,  etc.).  The 
Environment  is  also  classed  under  Physical. 

Event  has  three  major  subclasses:  Military  Event,  Civilian  Event,  and  Environmental  Phenomena. 
Environmental  Phenomena  includes  important,  but  transitory  events,  e.g.,  hurricanes,  floods,  and 
earthquakes,  which  are  occurrences  in  nature  rather  than  things  in  nature.  It  also  includes  (as  a  dis¬ 
tinct  subclass)  “conceptual  environmental  objects” — things  that  exist  in  the  environment  by  agree¬ 
ment,  such  as  borders,  shipping  lanes,  airways,  and  assembly  areas. 

In  the  past,  events  were  not  usually  directly  represented  in  the  classification  hierarchies  of  object 
systems;  however,  very  recent  thinking  in  the  field  has  legitimized  and  promoted  events  as 
classes  [9].  In  the  military  context,  it  is  not  difficult  to  think  of  categories  of  events  with  distinct 
attributes  and  behaviors. 

Agent  is  the  third  major  class.  Agents  initiate  actions  to  pursue  goals.  An  Agent  is  anything  that 
can  properly  be  said  to  have  goals,  desires,  motivation,  intentions,  and  plans.  Humans  and  organiza¬ 
tions  are  the  most  important  things  in  the  military.  “Agency”  is  their  core  unifying  idea. 

Human  and  Organization  are  linked  using  an  association  class.  Role.  Elements  that  exist  in  a  per¬ 
son’s  relationship  to  an  organization,  like  title,  rank,  seniority,  and  assignment  are  represented  in 
Role. 

Finally,  Command  and  Control  is  the  association  class  that  links  Physical,  Event,  and  Agent.  Com¬ 
mand  and  Control  unifies  the  people  and  organizations,  the  materiel,  the  missions,  the  environment, 
and  the  status  of  all  of  these  in  Missions  and  Information  Products — the  Plans,  Orders,  Situation 
Reports,  Messages,  Specified  and  Implied  Tasks,  etc.,  used  by  military  commands. 

Figure  E-1  shows  a  simplified  view  of  the  top-level  classes  and  their  relationships.  Section  7  and 
appendix  A  reiterate  and  elaborate  this  view  in  greater  detail. 
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Figure  E-1 .  The  top  level  of  the  taxonomy  unifies  materiel  and  environment,  events,  and  people 
and  organizations,  seen  from  the  point  of  view  of  a  CINC.  The  half  circle  above  command  and 
control  represents  an  association  relationship  that  Agent,  Physical,  and  Event  have  with  Command 
and  Control. 

No  single  taxonomy  will  encompass  all  possible  M&S  needs  at  all  levels  of  representation  and  res¬ 
olution.  Thus,  an  implicit  requirement  for  JWSOL  is  to  fit  as  seamlessly  as  possible  with  other  evolv¬ 
ing  taxonomies,  such  as  the  JTF— ATD  Schema,  the  NSS  taxonomy,  and  the  Multiwarfare  Assess¬ 

ment  and  Research  System  (MARS)  domain  representation.  JWSOL  and  related  programs  should  be 
mutually  supportive  and  co-evolving,  each  contributing  perspectives  and  expertise  to  the  others  so 
that  all  can  mutually  benefit.  Every  effort  must  be  made  to  have  different  perspectives  and  taxonomic 
proposals  for  achievement  of  common  goals  to  work  cooperatively. 
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1.  INTRODUCTION 


The  Joint  Warfare  Simulation  Object  Library  (JWSOL)  applies  object-oriented  analysis  and  design 
to  modeling  theater-level  joint  operations,  including  classes  for  theater  warfare  and  operations  other 
than  war.  A  repository  of  reliable,  robust,  reusable  warfare  simulation  classes  and  objects  will  be 
developed  that  can  be  used  to: 

•  Develop  and  populate  a  wide  range  of  joint  models  and  scenarios. 

•  Support  interoperation  of  both  new  and  legacy  models  and  simulations. 

JWSOL  sees  the  world  through  the  eyes  of  a  theater  Commander-in-Chief  (CINC).  This  perspec¬ 
tive  was  chosen  because  the  CINC  is  the  center  of  joint  operations,  and  the  challenge  of  analyzing 
truly  “joint”  command  and  control  (C^)  and  procedures  at  a  level  above  multi-Service  interoperabil¬ 
ity  starts  at  that  level. 

1.1  MOTIVATION 

Military  activities  are  increasingly  conducted  in  a  joint  environment.  This  revolution  in  military 
activities  has  been  brought  about  by  reductions  in  military  funding  and  resources  and  by  growth  in 
heterogeneity  of  threats  that  may  be  confronted. 

Much  of  the  “joint  simulation”  development  today  is  really  Service-specific  simulations  of  how 
function  and  activities  will  be  carried  out  independently  when  more  than  one  Service  participates  in 
an  operation.  This  approach  will  become  increasingly  unproductive. 

Robust  simulation  objects  and  a  comprehensive  simulation  framework,  with  Distributed  Interac¬ 
tive  Simulation  (DIS)  and  Common  Object  Request  Broker  Architecture  (CORBA)  compatibility, 
will  improve  the  power  of  future  simulations  while  simultaneously  cutting  costs  and  reducing  time- 
to-field. 

1.2  CURRENT  CHARACTER  OF  JWSOL 

JWSOL,  as  represented  in  this  document,  is  a  proposal  for  general-purpose  modeling  and  simula¬ 
tion  taxonomy  at  the  theater  level. 

Several  projects  are  addressing  the  use  of  object  technology  (OT)  in  modeling  and  simulation 
(M&S).  An  important  need  in  traditional  M&S,  recognized  by  the  Defense  Modeling  and  Simulation 
Office  (DMSO),  is  to  provide  a  common  language  before  fragmentation  and  a  “not  invented  here” 
syndrome  develops.  However,  although  JWSOL  is  a  response  to  this  need,  it  is  not  the  only  response. 
JWSOL  in  its  current  state  is  not  the  ‘Tmal  word”  in  warfare  class  hierarchies. 

Rather,  a  group  of  subject  matter  experts  (SMEs),  working  in  an  environment  designed  to  provide 
a  great  deal  of  freedom  of  conception,  has  attempted  to  represent  the  domain  clearly  and  simply.  A 
great  debt  is  owed  to  projects  like  the  Multiwarfare  Assessment  and  Research  System  (MARS)  and 
the  Navy  Taxonomy  that  preceded  JWSOL,  and  to  the  Joint  Task  Force-Advanced  Technology  Dem¬ 
onstration  (JTF-ATD)  Schema  (especially  to  the  Data  Server  work),  which  is  evolving  concur¬ 
rently. 

Ideas  have  flowed  freely  between  projects.  It  is  important  to  recognize  that  JWSOL  has  been  able 
to  proceed  without  the  intense  implementation  concerns  that  influence  the  Naval  Simulation  System 
(NSS),  MARS,  and  the  JTF-ATD  Schema.  Thus,  the  design  team  has  been  free  to  conceive  the 
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domain  without  strong  “local”  constraints.  The  proposal  put  forth  in  these  pages  reflects  that  free¬ 
dom. 

It  is  hoped  that  JWSOL  will  contribute  productively  to  the  evolving  M&S  community-wide  con¬ 
sensus  on  reusable  class  taxonomies.  Naturally,  the  authors  of  JWSOL  believe  that  it  is  a  powerful 
framework  and  starting  point.  But  the  bottom  line  is  use.  That  will  only  come  with  debate, 
compromise,  consensus,  and  a  principled  merging  of  top-down  and  bottom-up  issues  in  taxonomic 
representation. 

1.3  JOINT  WARFARE  TAXONOMY 

This  document  is  a  review  draft  of  the  JWSOL  object  taxonomy.  The  sections  leading  up  to  sec¬ 
tion  7  provide  context;  the  sections  after  discuss  plans  and  provide  reference  material.  Section  7,  the 
Taxonomy  Hierarchy,  and  appendix  A,  the  Rumbaugh  presentation  of  the  taxonomy,  are  the  heart  of 
the  document,  and  of  the  work  to  date. 

Section  2  discusses  the  goals  of  the  JWSOL  program.  Section  3  describes  the  potential  uses  and 
the  users  of  the  capability.  Section  4  reviews  the  status  of  JWSOL  and  briefly  summarizes  some 
related  programs.  Section  5  summarizes  the  requirements  detailed  in  the  August  1994  JWSOL 
Requirements  Definition  document,  and  discusses  some  further  requirements  for  an  effective  object 
repository.  Section  6  provides  a  quick  review  of  important  concepts  of  object  technology,  introduces 
the  taxonomic  notation,  and  discusses  interoperability,  the  Model  Request  Broker,  and  the  role  of 
JWSOL  in  supporting  both.  It  also  portrays  some  of  the  technical  difficulties  in  developing  a  taxon¬ 
omy.  Section  7  is  the  annotated  taxonomy.  Section  8  summarizes  the  current  and  projected  plans  for 
the  JWSOL  project. 
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2.  GOALS 


This  section  discusses  JWSOL’s  programmatic  and  modeling  and  simulation  goals.  JWSOL’s  pro¬ 
grammatic  goals  are  overarching  goals  that  ensure  JWSOL  meets  emerging  requirements  of  the  force 
as  a  whole.  JWSOL’s  M&S  goals  are  broad-based  technical  goals  that  influenced  the  JWSOL  analy¬ 
sis  and  specific  technical  goals  that  JWSOL  attempts  to  satisfy.  Following  these  discussions, 
JWSOL’s  relationship  to  the  DoD  master  plan  for  M&S  is  discussed. 

2.1  PROGRAMMATIC  GOALS 

2.1.1  Jointness 

JWSOL  established  four  programmatic  goals:  (1)  jointness;  (2)  communication,  cooperation,  and 
collaboration;  (3)  reuse;  and  (4)  results.  Future  U.S.  military  operations  will  require  an  increase  in 
both  the  number  of  joint  exercises  and  operations  and  the  degree  to  which  real  joint  command  and 
control  will  be  present.  Previously,  the  focus  of  modeling  and  simulation  efforts  has  been  on  plan¬ 
ning,  acquisition,  and  training  approaches  of  the  individual  Services.  Now,  however,  joint  activities 
have  come  to  the  forefront. 

2.1.2  Communication,  Cooperation,  and  Collaboration 

For  the  military  as  a  whole,  evolving  missions  combine  with  increasingly  tight  budgets  to  force 
more  interorganization  communication,  cooperation,  and  collaboration — both  within  and  across  Ser¬ 
vices.  JWSOL  will  provide  common  resources  and  languages  for  interaction. 

2.1.3  Reuse 

Time-to-field,  reliability  in  the  field,  and  monetary  constraints  make  reuse  important.  JWSOL 
facilitates  reuse  at  all  levels — conceptual,  analytic,  design,  and  eventually  code,  documentation,  and 
verification  and  validation  (V&V)  test  cases.  This  is  supported  by  the  use  of  object  technology  (OT); 
extensive  documentation  of  requirements  and  analysis,  along  with  the  rationale  for  design  choices; 
use  of  standard  notation  to  express  an  analysis;  and  representation  of  the  results  of  the  analysis  in 
both  book  and  electronic  (ParadigmPlus)  form.  Also,  the  active  involvement  of  JWSOL  personnel  in 
related  projects  such  as  the  Advanced  Research  Projects  Agency  (ARPA)  JTF-ATD  Object  Model¬ 
ing  Working  Group  (OMWG)  and  the  Navy  Simulation  System  (NSS),  has  served  to  develop  a  uni¬ 
fied  joint  approach  to  the  problem  domain  that  should  also  favorably  affect  or  encourage  reuse. 

2.1.4  Results 

The  JWSOL  approach  is  oriented  toward  results-based  modeling  of  joint  operations.  Several  prac¬ 
tical  and  cost-effective  technical  advantages  derive  from  this;  the  most  important  is  the  development 
of  JWSOL  using  commercial  object-oriented  languages  and  platforms. 

2.2  MODELING  AND  SIMULATION  GOALS 

The  broad-based  technical  goals  for  M&S  that  influenced  the  analysis  and  the  specific  technical 
goals  that  JWSOL  attempts  to  meet  are  discussed  below. 
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2.2.1  Broad-Based  Technical  Goals 

There  are  three  important  trends  in  M&S: 

•  Interoperaility,  both  among  new  developments  and  between  new  and  legacy  systems. 

•  Consistency  and  intelligibility  of  domain  representation. 

•  Flexibility  and  extensibility. 

As  a  library  of  common  objects,  JWSOL  will  promote  interoperation  of  new  models  and  simula¬ 
tions  in  the  simplest  possible  way — by  providing  common  representations,  behaviors,  and  interfaces 
for  a  range  of  warfare  objects.  Also,  JWSOL  will  provide  a  “language”  and  an  interface  specification 
for  interaction  with  new  (JWSOL-compliant)  models.  To  accomplish  this,  several  technical  require¬ 
ments  are  implied-: 

•  Platform  and  language  interdependence. 

•  Simulation  engine  architecture  and  approach  independence. 

•  User  environment  independence. 

Consistency  and  intelligibility  are  critical  for  credibility,  widespread  acceptance,  and  correct  use. 
The  fundamental  approach  of  JWSOL  has  been  to  adhere  to  a  “natural”  structure  based  on  the  cogni¬ 
tive  processes  and  realities  of  users  of  the  domain.  All  classes  and  objects  in  JWSOL  directly  and 
unambiguously  represent  real-world  objects.  To  resolve  any  question  regarding  JWSOL  classes  or 
objects,  the  real-world  analog  is  definitive. 

JWSOL  has  two  constraints  that  determine  the  fundamental  approach.  First,  JWSOL  must  be  gen¬ 
eral  in  purpose  but  not  ambiguous  in  structure.  There  is  tension  inherent  in  this  position:  the  less  spe¬ 
cific  the  perspective,  the  more  choices  exist  for  classification;  the  more  choices,  the  greater  the  risk 
of  arbitrariness.  A  naturalistic  approach  was  selected  as  a  means  to  minimize  artificiality.  The  point 
of  using  OT  is  to  aid  people  in  managing  complexity.  Simplicity  of  mapping  from  computational 
objects  to  the  real  world  is  the  key  to  managing  complexity.  Naturalism  is  the  simplest  possible  map¬ 
ping.  There  is  a  risk  in  this  approach,  however.  Although  consistent  with  the  current  best  practices  in 
OT,  it  is  not  the  only  way  to  classify. 

Flexibility  and  extensibility  are  also  required.  Flexibility  is  inherent  in  using  class  templates  and 
inheritance  to  define  instances.  The  possibilities  are  limited  only  by  the  imagination.  Extensibility 
refers  both  to  extension  outward  to  a  greater  number  of  subjects  or  layers  of  command,  and  to  exten¬ 
sion  inward  to  greater  degrees  of  resolution  for  the  things  represented.  For  outward  extension, 
JWSOL  provides  a  domain  representation  and  a  reference  point.  Inward  expansion  is  doable,  but 
more  complex. 

Dealing  with  multiple  resolutions  is  currently  one  of  the  most  difficult  M&S  issues.  Resolutions 
range  from  theater-level  model  components  like  JWSOL  to  ultra-fine-grained  models  like  AREA’ s 
“smart  product  models,”  200-gigabyte  acquisition  models  that  incorporate  performance,  reliability, 
and  even  computer-aided  design/computer-aided  manufacturing  (CAD/CAM)  information.  Not  only 
is  there  a  wide  range  of  resolutions,  but  there  is  the  related  problem  of  “perspectives”;  that  is,  out¬ 
side”  model  entities  may  not  be  authorized  and/or  have  the  (simulated)  capability  to  see  particular 
model  objects  in  their  ground  truth  state  (i.e.,  for  a  particular  model.  Element  A  can  only  see  high- 
resolution  Element  B  at  low,  or  even  fuzzy,  resolution). 

Second,  JWSOL  is  descriptive,  not  prescriptive.  Normal  terminology  and  normal  meanings  are 
used  for  concepts.  To  the  extent  that  military  doctrine  provides  meanings  for  terms  and  references. 
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users  will  build  on  those  terms  when  employing  JWSOL.  The  user  will  not  have  to  learn  new  ter¬ 
minology  or  use  labels  differently  in  JWSOL  than  are  used  in  the  real  world. 

The  naturalistic  approach  has  wide  acceptance.  The  JTF— ATD  Schema,  NSS,  and  MARS  all 

take  this  approach.  Consequences  of  this  approach  include  the  following: 

1.  The  occurrence  of  pure  abstractions,  or  metaclasses,  are  minimized.  JWSOL  does  have 
“land  vehicles,”  “vessels,”  and  “aircraft.”  The  bias,  however,  is  to  actual  things.  An  impor¬ 
tant  caveat  is  that  the  military  domain  is,  in  general,  as  equally  rich  in  concepts  as  it  is  in 
things.  Some  “things”  are  appropriately  conceptual,  e.g.,  a  Division  Commander  may  think 
in  terms  of  Armored  Brigades,  whereas  a  Platoon  Commander  may  think  in  terms  of  tanks. 
Because  of  this,  the  natural  notion  triggered  by  a  class  name  is  intended  to  meaningfully 
constrain  the  class  content. 

2.  As  with  classes,  so  with  relationships.  A  thing  has  a  location  in  space  and  time.  It  is  only 
from  an  organizational  or  planning  perspective  that  it  is,  for  example,  part  of  a  “concentra¬ 
tion  of  force.”  So  that  relationship  (membership  in  “concentration  of  force”)  is  represented 
at  the  organizational  level,  where  it  exists  in  the  real  world,  but  not  at  the  tank  or  artillery 
piece  level. 

3.  There  are  no  simulation  classes  or  objects  in  JWSOL.  JWSOL  does  not  have  an  “event 
queue”  object,  a  “time-step”  object,  or  a  “display  summary  statistics”  object.  JWSOL  is  not 
a  model,  or  even  a  model  construction  toolkit.  This  is  a  significant  difference  between 
JWSOL  and  (for  example)  the  JTF-ATD  Schema,  which  will  include  both  domain 
objects  and  modeling  classes. 

The  Composite  Warfare  Model  (CWM),  a  Navy  simulation  used  successfully  by  the  Space  and 
Naval  Warfare  Systems  Command  (SPAWAR)  and  others,  uses  a  fairly  radical  decomposition  in 
which  most  attributes  and  methods  are  in  their  own  class.  Objects  may  have  hundreds  of  super¬ 
classes.  Written  in  Common  Lisp,  CWM  is  “linguistically  advantaged”  for  this  approach;  however,  it 
stands  as  a  counterexample  to  the  naturalistic  approach.  For  multiple  users,  with  differing  needs  and 
backgrounds,  naturalism  is  appropriate;  however,  this  is  a  hypothesis,  and  in  the  world  of  simulation, 
CWM  has  been  at  least  as  successful  as,  say,  MARS  (a  more  naturalistic  object-oriented  simulation). 

Another  related  hypothesis  is  that  a  general-purpose  taxonomy  will  be  useful.  This  is  not  as 
obvious  as  it  seems.  Consider  underwater  detection.  From  a  generalist  (and  naturalist)  point  of  view, 
the  way  to  model  it  would  be  to  have  a  sensor,  a  target,  and  the  environment.  The  sensor  would  be 
responsible  for  its  own  range  and  sensitivity,  the  target  for  its  signature  (e.g.,  noise,  wake,  emissions, 
electromagnetic  presence),  and  the  environment  for  its  transparency  or  opacity  with  respect  to  the 
sensor.  However,  in  undersea  detection  modeling,  all  three  of  these  distinct  classes,  sensor,  target, 
and  environment,  are  often  grouped  together  into  “detection  environment,”  and  very  specific  models 
are  produced  to  model  the  interactions.  If  JWSOL’s,  and,  as  has  been  noted,  JTF— ATD  C^  Schema’s 
and  NSS’s  hypotheses  are  that  general  models’  advantages  outweigh  the  power  of  specialized  mod¬ 
els,  the  challenge  is  to  demonstrate  this  in  fact. 

2.2.2  Specific  Technical  Goals 

JWSOL  must  first  support  M&S  at  the  theater  (joint)  level.  This  will  develop  “joint”  objects  that 
can  be  easily  adapted  for  reuse  by  component  Services  in  more  limited  M&S  efforts.  The  objects  will 
support  models  and  simulations  for  operations,  tactics  and  doctrine,  performance  enhancement,  and 
training. 
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JWSOL  must  serve  as  a  repository  of  reliable,  robust,  reusable  warfare  simulation  classes  and 
objects  that  can  be  used  to  develop  and  populate  a  wide  range  of  joint  models  and  scenarios.  In 
object-oriented  technology  (OOT),  the  domain  decomposition  process  is  highly  subjective.  This 
results  in  serious  design  differences  and  incompatibilities  that  hinder  interoperability  in  the  Joint 
M&S  industry.  The  JWSOL  team  has  used  SMEs  collectively  to  identify  the  objects  through  an  itera¬ 
tive  process,  thereby  fostering  compatibility.  This  approach  increases  the  potential  for  object  reuse, 
thus  minimizing  development  and  maintenance  costs.  The  object  library  will  be  designed  to  support 
the  seamless  exchange  of  information  between  separate  simulations,  both  within  and  between  the 
Services. 

Despite  the  extensive  cutbacks  in  funding  and  personnel  across  the  Services,  there  is  a  growing 
requirement  for  “jointness”  in  tactical  theater-level  planning  and  exercises.  Too  often  only  lip-service 
has  been  paid  to  the  term  “joint.”  Individual  Services  develop  “joint”  models  that  merely  address 
how  that  Service  will  perform  in  a  joint  environment.  Often,  as  a  result,  multiple  models  or  simula¬ 
tions  are  developed  to  support  the  same  overall  functional  or  joint  mission  area.  These  models  fre¬ 
quently  are  incompatible  and  fail  to  achieve  a  true  replication  of  joint  functionalities. 

2.3  RELATIONSHIP  OF  JWSOL  TO  DoD  MASTER  PLAN  FOR  MODELING  AND 
SIMULATION 

The  DMSO  Master  Plan  for  “DoD  Modeling  and  Simulation  (M&S)  Management”  implements 
DoD  5000.59  policy;  establishes  DoD-wide  M&S  objectives;  provides  a  comprehensive  framework 
for  the  planning,  programming,  and  budgeting  of  M&S  projects;  and  assigns  responsibilities  for  its 
implementations.  The  “vision”  for  M&S  described  in  this  plan  addresses  the  following; 

Defense  modeling  and  simulation  will  provide  readily  available,  operationally  valid  environ¬ 
ments  for  use  by  DoD  components: 

-  To  train  jointly,  develop  doctrine  and  tactics,  formulate  operational  plans,  and  assess  war¬ 
fighting  situations, 

-  To  support  technology  assessment,  system  upgrade,  prototype  and  full-scale  development, 
and  force  structuring. 

Furthermore,  common  use  of  these  environments  will  promote  a  closer  interaction  between  the 
operations  and  acquisition  communities  in  carrying  out  their  respective  responsibilities.  To 
allow  maximum  utility  and  flexibility,  these  modeling  and  simulation  environments  will  be  built 
from  affordable,  reusable  components  interoperating  through  an  open  systems  architecture. 

A  baseline  M&S  assessment  has  identified  several  shortfalls  that  must  be  corrected  in  order  to 
realize  the  vision  described  above.  These  shortfalls  are  addressed  in  six  DoD-wide  objectives; 

1.  Establish  a  common  high-level  simulation  architecture  to  ensure  the  appropriate  interoper¬ 
ability  of  live,  virtual,  and  constructive  simulations,  and  their  interface  with  command,  con¬ 
trol,  communications,  computers,  and  intelligence  (C^I)  systems. 

2.  Provide  timely  and  authoritative  representations  of  the  natural  environment. 

3.  Provide  authoritative  representations  of  systems. 

4.  Provide  authoritative  representations  of  human  behavior. 

5.  Establish  an  M&S  infrastructure  to  meet  developer  and  end-user  needs. 

6.  Share  the  benefits  of  M&S. 
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JWSOL  addresses  the  first  objective  above  by  providing  a  comprehensive  library  of  objects  that 
can  be  used  in  a  variety  of  models  and  simulations  across  the  Services.  In  the  development  of  this 
object  library,  JWSOL  has  emphasized  the  identification  of  requisite  environmental  objects  (objec¬ 
tive  2).  JWSOL  places  a  priority  on  the  natural  environment,  including  environmental  effects  on  sys¬ 
tems  and  system  effects  on  the  environment.  The  expertise  of  SMEs  has  been  used  in  the  identifica¬ 
tion  of  system  objects  (e.g.,  vehicles,  weapons,  and  command,  control,  communications,  and 
intelligence  (C^I)  systems  [objective  3]).  This  same  expertise  is  identifying  objects  necessary  to  sup¬ 
port  the  decision-making  process,  with  emphasis  on  decision  making  under  stress  (objective  4).  The 
library  will  provide  a  capability  that  will  simplify  the  M&S  developer’s  task  and  meet  the  end-user’s 
need  (objective  5).  The  standardization  of  objects  will  help  ensure  consistency  in  simulation  results, 
simplify  maintenance,  foster  code-sharing,  and  promote  interoperability.  The  reusable  and  tailorable 
objects  will  aid  in  the  interfacing  of  models  and  simulations  both  within  and  between  Services 
(objective  6). 

The  DoD  M&S  Master  Plan  addresses  10  technical  goals  for  a  high-level  simulation  architecture: 

1 .  Entity-level  representation 

2.  Interoperability 

3.  Reuse 

4.  Portability 

5.  Distributed  operation 

6.  Legacy  interface 

7.  Scalability 

8.  Broad  functional  applicability 

9.  Technological  evolvability 

10.  Commercial  off-the-shelf/government  off-the-shelf  (COTS/GOTS)  use 
These  goals  are  also  objectives  of  JWSOL. 
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3.  USES  AND  USERS 

JWSOL  is  a  theater-level  object  library.  Unified  commands  exist  to  pursue  U.S.  strategic  goals  at 
the  political  and  military  levels.  Political  issues  and  concerns  are  beyond  the  scope  of  this  document, 
but  they  underlie  much  of  what  the  Unified  CINC  does  on  a  day-to-day  basis.  Military  strategy  at  the 
CINC  level  involves  the  application  of  military  force  to  accomplish  the  mission(s)  assigned  by  the 
National  Command  Authority  (NCA),  the  President,  and  the  Secretary  of  Defense. 

Typically,  military  commanders  conceptualize  their  forces  two  levels  below  their  own.  In  the  two- 
tiered  Theater  Command  structure  shown  in  figure  1  (CINC  directly  to  the  JTF  Commander)  used  in 
JWSOL,  combat  and  sustainment  capabilities  of  small  tactical  level  units  are  aggregated  to  the  level 
of  composite  division/separate  brigade  and  their  equivalents.  Although  squads  and  platoons  are  not 
shown,  they  are  represented  in  the  roll-up  numbers  of  equipment  and  personnel  assigned  to  parent 
organizations.  This  section  goes  into  more  detail  on  what  analysis  areas  it  is  suitable  for,  how  it  can 
be  used  within  those  areas,  and  who  can  use  it.  Although  this  approach  appears  truncated,  it  is 
intended  that  further  refinements  of  the  taxonomy  delve  deeper  into  smaller  unit  levels. 

3.1  M&S  USE  AREAS 

JWSOL  is  being  designed  with  multiple  applications  in  mind. 

Operational  applications  include  operational  planning,  course-of-action  (COA)  development  and 
evaluation,  and  reconstruction  of  operations  to  facilitate  lessons-leamed  studies.  These  can  be  either 
real-time  or  deliberate.  JWSOL  will  provide  a  strong  set  of  validated  base  class  definitions  and 
objects  for  these  activities. 

Decision  support  includes  threat  modeling,  “what-if  ’  analyses,  planning  support  in  all  military 
functional  areas,  automated  critiquing,  wargaming,  and  expert  systems.  A  future  release  of  JWSOL 
will  provide  explicit,  fully  integrated  user-modifiable  knowledge  representation  (with  change  autho¬ 
rization  control),  along  with  limited  support  for  platform-independent  multimedia  presentation, 
including  integration  of  knowledge  representation  and  reasoning  with  textual,  graphical,  video, 
sound,  mapping,  and  data  visualization.  A  variety  of  government  off-the-shelf  (GOTS)  tools  exists 
for  knowledge  representation  and  reasoning  (e.g.,  CLIPS,  KRSL).  With  respect  to  multi-  and  hyper¬ 
media,  the  JTF-ATD  exploration  of  web-based  blackboards  is  extremely  interesting. 

Logistics  includes  detailed  planning  and  execution  monitoring  in  mobilization,  transportation,  sus¬ 
tainment,  consumption  forecasting,  and  dealing  with  temporal  dependencies  and  constraints.  As 
above,  a  robust  set  of  validated  class  definitions  and  objects  supports  logistics  analysis. 

Training  has  special  needs.  The  domain  of  joint  training  is  just  now  evolving  into  a  discrete  mili¬ 
tary  function.  In  anticipation  of  emerging  needs  to  support  joint  training,  the  Universal  Joint  Task 
List  (UJTL),  published  by  J-7  of  the  Joint  Staff,  has  been  used  as  a  fundamental  document.  The 
UJTL  is  a  superb  source  of  theater-strategic-level  tasks,  conditions,  and  standards  that  must  be 
accomplished  by  theater  CINCs  and  their  staffs.  For  training,  these  tasks  must  therefore  be  “model- 
able,”  using  objects  in  JWSOL.  Trainers  may  need  to  loosen  otherwise  firm  constraints  in  order  to 
exercise  at  boundary  conditions  and  to  concurrently  manage  both  ground  truth  and  perceived  situa¬ 
tions  for  multiple  threats  or  users.  JWSOL  currently  supports  only  ground  truth.  However,  the  notion 
of  “perspectives,”  discussed  in  section  6,  is  a  natural  and  seamless  extension  of  JWSOL’s  current  tax¬ 
onomic  structure.  Perspectives  would  support  perceived  situations  while  preserving  an  explicit 
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Figure  1 .  Representation  of  a  two-tiered  theater  command  and  control  organization,  showing  the  more  widely  used  Service  (vice 
functional)  components.  The  solid  lines  show  operational  control.  The  dotted  lines  show  administrative  relationships.  The  lower  shaded 
area  shows  the  depth  to  which  CINC  would  look — which  is  the  depth  to  which  JWSOL  goes  in  its  taxonomic  representation. 


separation  of  ground  truth  front  perception.  JWSOL  will  also  be  suitable  for  support  of  exercises  and 
synthetic  environments  should  it  be  incorporated  into  a  Model  Request  Broker  (discussed  briefly 
below  and  in  more  detail  in  section  6.2)  or  used  directly  as  a  standard  or  part  of  a  standard  for  model 
interoperation. 

Acquisition  is  a  significant  area  of  military  modeling.  An  interesting  development  in  acquisition  is 
the  increasing  emphasis  on  independent  validation  of  mission  effectiveness  improvement  for  pro¬ 
posed  acquisitions.  In  the  past,  the  same  agencies  and  program  offices  that  were  promoting  a  particu¬ 
lar  acquisition  would  also  build  models  to  measure  the  positive  consequences  of  making  the  very 
acquisition  they  were  advocating.  Recently,  there  has  been  increased  awareness  that  independent  val¬ 
idation  is  necessary.  This  is  part  of  the  impetus  for  the  unified  High-Level  Architecture.  JWSOL  has 
the  potential  to  be  a  neutral  provider  of  domain  objects  against  which  a  potential  acquisition  can  be 
tested. 

3.2  CLASSES  OF  USE 

The  JWSOL  object  taxonomy  can  be  used  to  develop  new  models  and  simulations  and  as  a 
medium  for  interoperation  between  independently  developed  M&S  systems. 

Development  of  new  models  using  JWSOL  objects  is  simplified.  There  are  three  parts  to  construc¬ 
tion  of  a  new  model  or  simulation;  modeling  the  subject  domain,  providing  the  computational  infra¬ 
structure,  and  developing  the  user  environment  and  its  scenario  generation  and  postanalysis  tools.  It 
is  generally  considered  that  the  first  of  these  is  the  most  important;  JWSOL  facilitates  this  activity. 

JWSOL  supports  interoperability  on  three  levels. 

Directly.  Models  that  use  JWSOL  objects  will  have  a  direct,  object-to-object  correspondence. 
Interoperation  can  then  either  be  within  a  workspace,  or  across  workspaces,  mediated  by  operating 
system  or  distribution  operating  systems  calls,  or  via  CORBA. 

Indirectly.  JWSOL  class  definitions  will  provide  an  interface  template  that  could  be  used  to  gener¬ 
ate  container  objects  for  either  DIS-compliant  or  non-DIS  models  and  simulations.  Any  simulation 
using  JWSOL  class  definitions  or  objects  in  its  external  interface  would  then  be  able  to  take  advan¬ 
tage  of  the  direct  style  of  interoperation  described  in  the  preceding  paragraph. 

Via  a  Model  Request  Broker.  A  Model  Request  Broker  (MRB),  analogous  to  an  Object  Request 
Broker  but  on  a  higher  level  of  abstraction,  could,  if  implemented,  provide  a  standardized  interface 
for  model  interaction.  The  Interface  Definition  Language  (IDL)  equivalent  for  an  MRB  should  be  a 
set  of  standard  templates  of  entity  and  nonentity  level  interactions.  JWSOL  class  definitions  are 
exactly  such  a  set  of  templates.  JWSOL  is  a  leading  candidate  for  incorporation  in  an  MRB,  should 
the  project  that  proposed  the  idea,  the  Navy  Simulation  System  (NSS),  continue  into  MRB  develop¬ 
ment. 

3.3  LEVELS  OF  USE 

JWSOL  will  be  used  at  four  levels:  the  user/analyst,  the  content  modeler,  the  perspectives  modeler, 
and  the  programmer.  At  the  user/analyst  level,  class  definitions  and  objects  will  be  used  (in  the  con¬ 
text  of  particular  simulation  environments)  to  assemble  models  and  model  components  for  simula¬ 
tion.  This  level  of  use  is  appropriate  for  both  program  and  warfare  analysts,  and  for  decision-makers. 
Content  modelers  will  be  able  to  edit  values  and  attributes  of  specific  warfare  and  environmental 
classes,  and  will  be  able  to  combine  classes  in  novel  ways  to  test  the  effects  of  such  combinations. 
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In  a  future  version  of  JWSOL,  perspective-modelers,  primarily  trainers,  will  be  able  to  explicitly 
control  the  perspectives  available  to  users  and,  through  both  attribute  value  assignment  and  knowl¬ 
edge  representation,  the  situations  their  trainees  will  encounter.  Finally,  programmers  will  have 
access  to  industry-standard  object-oriented  analysis  and  design  materials,  professional-quality  docu¬ 
mentation,  and  implemented  objects. 

3.4  COEVOLUTION  WITH  OTHER  PROGRAMS 

As  indicated  above  (section  1.2),  JWSOL  is  a  contribution  to  a  broad  M&S  community  “discus¬ 
sion”  of  taxonomic  and  domain  representation  issues.  JWSOL  has  significantly  interacted  with  two 
programs;  NSS  and  JTF-ATD  Object  Modeling  Working  Group  (OMWG). 

NSS  is  a  multiyear  project  to  develop  a  single,  unified.  Navy-wide  architecture  for  modeling  and 
simulation.  NSS  is  innovative  in  several  respects: 

•  NSS  emphasizes  fielding  operational  software.  The  first  release  of  NSS  will  be  installed  at 
Commander  in  Chief,  U.S.  Pacific  Fleet  (CINCPACFLT)  by  August  1995.  Subsequent  major 
releases  are  scheduled  at  1 2-month  intervals. 

•  NSS  programmatically  unifies  a  number  of  distinct  Navy  and  Marine  laboratories  and  com¬ 
mands  into  a  cooperative,  collaborative  development  team. 

•  NSS  incorporates  distributed,  lab-authority-centered  verification,  validation,  and  accreditation 
(VV&A)  from  the  beginning. 

•  NSS  is  participating  in  the  DMSO  effort  to  define  a  DoD-wide  generic  High-Level  Architec¬ 
ture  described  in  the  DoD  Master  Plan  for  Modeling  and  Simulation  (discussed  in  section  2.3). 

NSS  Release  1  has  already  incorporated  JWSOL  preliminary  taxonomic  elements.  It  is  anticipated 
that  Release  2  will  further  use  maturing  JWSOL  classes.  JWSOL  technical  staff  are  closely  following 
the  ongoing  development  of  NSS,  so  that  any  changes  the  NSS  team  feels  are  needed  to  be  effective 
for  their  domain  can  be  assimilated  (as  appropriate)  into  JWSOL.  A  productive  dialog  exists  and 
continues  to  be  nurtured,  with  each  party  benefiting  from  the  work  of  the  other. 

The  JTF-ATD  OMWG  is  supporting  the  large  JTF-ATD  activity  by  defining  the  Command  and 
Control  (C^)  Schema,  considered  by  the  technical  directors  of  the  various  subactivities  to  be  the 
“glue”  that  will  hold  the  entire  project  together.  Not  only  have  JWSOL  team  members  been  active  in 
the  OMWG,  but  many  JWSOL  classes  and  class  relationship  structures  have  been  directly  adopted 
by  the  OMWG  as  well  as  by  the  Data  Server  group  within  the  JTF-ATD. 

So  this  is  not  misconstrued,  knowledge  and  insight  have  flowed  from  the  OMWG  and  the  Data 
Server  to  JWSOL  as  much  as  vice  versa.  The  OMWG  has  provided  both  breadth  and  depth  of 
knowledge  in  several  areas,  resulting  in  significant  improvements  to  the  JWSOL  taxonomy  presented 
here.  In  the  wide  area  of  shared  perspective,  similar  enough  structures  evolved  independently  that 
little  effort  was  required  to  join  them  into  a  single  representation.  The  relationship  between  JWSOL 
and  the  JTF-ATD  OMWG  and  Data  Server  has  been  productive. 

However,  JWSOL,  the  JTF-ATD  C^  Schema,  and  the  JTF-ATD  Data  Server  each  have  different 
requirements  and  constraints.  In  the  wide  area  where  there  is  a  strong  overlap,  it  is  hoped  that  the 
productive  mutual  support  seen  thus  far  will  continue  and  thrive.  JTF-ATD  program  manager 
Dr.  John  Schill  has  described  the  JTF-ATD  design  as  a  “maximum-theft  architecture” — meaning  that 
he  hoped  as  much  of  the  JTF-ATD  design  and  development  work  as  could  be  broadly  used  would  be 
broadly  used.  JWSOL  is  in  complete  agreement,  with  no  restrictions  on  the  direction  of  influence. 
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4.  PROGRAM  CONTEXT 


This  section  reviews  the  genesis  and  status  of  JWSOL  and  acknowledges  two  related  programs 
that  have  been  of  value  and  have  influenced  the  JWSOL  program. 

4.1  HISTORY  AND  STATUS  OF  JWSOL 

In  December  1992,  the  Naval  Command,  Control  and  Ocean  Surveillance  Center  RDT&E  Divi¬ 
sion  (NRaD)  submitted  a  proposal  in  response  to  DMSO’s  FY  93  Focused  Call  for  Projects.  The  pro¬ 
posed  effort  was  to  produce  a  set  of  software  “objects”  for  use  in  object-oriented  simulation  of  war¬ 
fare.  DMSO  recognized  the  need  for  Joint  Service  research  of  the  application  of  object  technology 
(OT)  design  to  the  domain  of  warfare  and,  in  August  1993,  the  3-year,  three-phase  JWSOL  program 
was  initiated  with  DMSO  funding.  The  JWSOL  approach  addresses  the  goals  and  objectives  as 
defined  in  the  DMSO  Master  Plan  and  as  stated  in  section  2.3. 

The  first  phase  of  the  program  has  resulted  in  a  comprehensive  joint  warfare  requirements  defini¬ 
tion  [5]  and  the  decomposition  of  the  warfare  process  into  objects,  as  represented  in  this  taxonomy 
document.  This  work  was  accomplished  by  a  Joint  Service  C^  laboratory  team.  Warfare  analysts, 
representing  each  Service,  participated  in  identifying  and  specifying  each  Service’s  joint  simulation 
requirements  in  collaboration  with  an  OT  design  expert  and  NRaD  personnel.  This  effort  resulted  in 
a  comprehensive  taxonomy,  or  OT  hierarchical  design  of  joint  warfare  simulation  requirements, 
which  is  a  necessary  first  step  toward  having  DoD  simulation  projects  that  will  interoperate  with 
other  simulations.  The  requirements  and  preliminary  taxonomy  were  validated  against  Joint  Chiefs 
of  Staff  (JCS)  policy,  and  comments  from  a  comprehensive  review  were  incorporated. 

The  second  phase,  development  of  the  object  specifications  for  the  warfare  objects,  is  being  initi¬ 
ated.  These  specifications  are  being  documented  in  an  object  model  using  Rumbaugh  notation.  The 
construction  of  the  object  specifications  during  this  second  phase  of  the  JWSOL  effort  will  be  an 
iterative  process  of  prototyping  and  documenting.  Iterations  will  continue  until  the  entire  set  of 
objects,  with  their  related  inheritance  hierarchies  and  “part  of’  hierarchies,  merges  in  a  final  design. 
The  third  phase  consists  of  fielding,  filling,  verifying,  and  validating,  as  well  a  maintaining,  the 
JWSO  Library. 

4.2  RELATED  PROGRAMS:  JSIMS  AND  JWID  95 

The  Joint  Simulation  System  (JSIMS)  is  a  joint  effort  being  supported  by  the  military  Services  to 
provide  more  disciplined  development,  better  focus,  and  significant  M&S  investment  economies  of 
scale  while  increasing  both  the  reliability  and  the  credibility  of  component  Service  M&S  tools.  His¬ 
torically,  the  Services  have  independently  developed  training  models  and  simulations.  This  has 
resulted  in  duplication,  interface  problems,  data-sharing  difficulties,  and  inefficient  investment  of 
critical  dollars.  JSIMS  will  include  missions  across  the  full  range  of  military  operations.  The  system 
will  address  the  complete  joint  and  multinational  operational  environment.  JSIMS  is  being  designed 
to  support  those  tasks  addressed  in  the  UJTL  published  by  the  Joint  Staff. 

The  JWSOL  effort  is  attempting  to  be  responsive  to  JSIMS  needs,  so  valuable  review  of  JWSOL 
documentation  and  comments  on  JWSOL  SME  taxonomic  recommendations  have  been  provided  by 
JSIMS  personnel.  The  JSIMS  primary  operational  goal  of  using  object-oriented  design  techniques 
for  reusability,  portability,  and  interoperability  of  object-based  software  components  in  distributed 
environments  is  supported  by  JWSOL  objectives.  Also,  to  ensure  joint  interoperability  of  products, 
both  the  UJTL  and  JSIMS  were  used  as  sources  of  JWSOL  functional  requirements. 
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Planning  is  well  underway  for  Joint  Warrior  Interoperability  Demonstration  (JWID)  95.  Sched¬ 
uled  for  the  last  two  weeks  in  September  1995,  JWID  95  will  focus  on  Disaster  Relief  and  Huma¬ 
nitarian  Assistance.  A  wide  variety  of  participants  representing  the  various  Services  will  demonstrate 
the  applicability  of  a  multitude  of  technologies  in  this  collaborative  planning  exercise.  This  JWID 
will  build  on  the  lessons  learned  from  JWID  94.  JCS  priorities  for  JWID  95  include  focusing  on  the 
warfighter  and  basing  the  scenario  on  current  events,  including  a  Hurricane  Andrew-type  storm  to 
generate  a  domestic  disaster  relief  effort  in  Hawaii. 

The  JWSOL  taxonomy  and  objects  will  be  provided  to  the  JWID  planners  to  support  the  interoper¬ 
ability  of  simulations.  In  concert  with  the  JTF-ATD  Schema,  this  will  help  minimize  develop¬ 
ment  co.sts  while  promoting  the  seamless  exchange  of  objects  between  simulations  of  multiple  Ser¬ 
vices. 
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5.  REQUIREMENTS 


5.1  JWSOL  REQUIREMENTS  DOCUMENT 

The  JWSOL  taxonomy  is  the  product  of  extensive  requirements  analysis,  recorded  in  the  JWSOL 
Requirements  Definition  [5].  The  warfare  domains  of  each  Service  are  so  extensive  that  a  boundary 
needed  to  be  defined  in  order  to  focus  on  objectives  that  could  be  realized  and  demonstrated  in  a  rel¬ 
atively  short  period  of  time.  The  theater  tactical  level  of  warfare  was  selected.  Specifically,  require¬ 
ments  were  specified  to  support  the  command  decision-making  process  at  that  level. 

Subject  matter  experts  representing  the  Services  used  the  Joint  Staff’s  Unified  Joint  Task  List 
(UJTL)  [13],  AFSC  Pub  1 — The  Joint  Staff  Officer’s  Guide  1993  [1],  and  the  Training  and  Doctrine 
Command’s  (TRADOC’s)  Pamphlet  No.  1 1-9 — Blueprint  of  the  Battlefield  [12].  as  a  foundation  for 
the  requirements  definition.  The  requirements  identified  for  JWSOL  were  divided  into  six  sections: 
general,  Joint,  Army,  Navy,  Marine,  and  Air  Force  requirements. 

The  JWSOL  Requirements  Definition  document  specifies  what  must  be  done,  not  how  the  work  is 
to  be  done.  The  development  of  the  requirements  document  was  a  necessary  precursor  to  the  design 
or  implementation  phase.  It  provided  important  information  that  has  minimized  risk  and  aided  in  the 
efficient  expenditure  of  resources.  The  identified  requirements  were  used  to  produce  the  warfare 
objects  specified  in  this  taxonomy. 

5.2  MISSIONS  AND  THEIR  IMPLICATIONS 

The  JWSOL  taxonomy  was  defined  from  the  missions  the  GINC  may  need  to  accomplish.  Mission 
diagrams,  shown  in  figures  2  through  5: 

•  Map  the  joint  mission  area  to  the  JWSOL  Requirements, 

•  Show  the  Service(s)  involved  in  the  mission  area, 

•  Identify  the  taxonomic  command  headquarters, 

•  Identify  the  unit(s)  taking  the  action(s), 

•  Show  the  class(es)  of  object  accomplishing  the  action,  thus  completing  a  “mission  thread” 
from  joint  command  level  through  and  including  the  major  equipment  object,  which  is  used  to 
fulfill  the  mission. 

Two  additional  diagrams,  figures  6  and  7,  are  functional  representations  of  the  intelligence  and 
sustainment  processes.  These  are  critical  supporting  mission  areas  that  must  be  represented  for  plan¬ 
ning  at  the  theater  level.  They  are  included  in  the  JWSOL  approach  along  with  operations  because  of 
their  importance  and  their  representation  in  the  UJTL. 

5.3  VERIFICATION  AND  VALIDATION  (V&V) 

Verification  refers  to  software  systems.  A  verified  system  fulfills  its  specification  and  operates 
without  fault.  Validation  applies  both  to  software  and  to  the  content  of  models  and  simulations.  Val¬ 
idation  means  that  the  content  is  correct  with  respect  to  the  problem  to  be  solved  or  the  material  to  be 
represented.  Authentication,  an  additional  qualifier,  refers  only  to  models,  and  means  that  authorized 
SMEs  affirm  that,  within  a  specified  context  and  level  of  resolution,  and  with  respect  to  a  specified 
use,  the  model  truly  reflects  reality.  JWSOL  is  not  intended  to  result  in  the  delivery  of  a  working 
model.  Therefore,  verification  does  not  apply  to  this  effort. 
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Validation  is  the  only  element  of  V&V  that  currently  applies  to  JWSOL.  The  normal  best  practice 
for  domain  content  validation  is  to  offer  the  representation  to  the  scrutiny  of  SMEs,  solicit  their  com¬ 
ments,  and  incorporate  their  corrections.  This  necessary  subject  matter  expertise  has  been  incorpo¬ 
rated  in  the  composition  of  the  task  team — ^Army,  Navy,  Marine,  Air  Force,  and  environment  SMEs 
form  the  core.  In  addition,  requirements  have  been  submitted,  and  this  document  will  be  submitted  to 
a  wide  range  of  SMEs  for  examination  and  critique. 

5.4  RELEVANT  STANDARDS 

Two  classes  of  relevant  standards  pertain  to  the  JWSOL  effort:  software  environment  and  interop¬ 
eration. 

JWSOL  is  neutral  with  respect  to  software  environment  and  programming  tools.  If  JWSOL  is 
implemented,  then  specific  choices  of  platform,  language,  and  configuration  management  tools  will 
have  to  be  made.  To  enable  and  encourage  reuse,  it  is  anticipated  that  the  analysis  and  design  would 
be  maintained  at  a  level  above  the  implementation. 

There  are  two  relevant  standards  at  the  model  interoperation  level:  DIS  and  CORE  A.  DIS  is  a 
body  of  protocols  for  real-time  interoperation  of  legacy  simulations  at  the  entity  level.  DIS,  running 
over  the  Defense  Simulation  Internet  (DSI),  has  been  highly  successful,  and  has  been  the  enabling 
technology  for  sophisticated  synthetic  environments  and  both  live  and  virtual  simulations. 

COREA  is  now  in  Release  2.0.  COREA  is  the  key  enabling  technology  for  distributed  objects. 
COREA  allows  a  C"'"''  object,  running  on  a  Sun  workstation,  to  send  and  receive  messages  from  a 
Common  Lisp  object,  running  on  a  Power  Macintosh.  Also  using  COREA,  the  Common  Lisp  object 
can,  in  turn,  receive  and  send  messages  to  a  SmallTalk  object  running  on  an  lEM  Power2  server. 
COREA  is  the  product  of  extended  negotiations  among  major  software  development  houses  and 
research  organizations  (both  private  and  government).  It  is  a  mature  standard  for  object  interopera¬ 
tion  across  software  and  hardware  platforms  and  languages. 

JWSOL,  as  a  source  for  stand-alone  model  development,  is  independent  of  both  DIS  and  COREA. 
Eoth  are  appropriate  for  interoperable  JWSOL  models.  Eoth  can  safely  be  deferred  to  the  imple¬ 
mentation  phase. 

5.5  PROJECTED  REQUIREMENTS 

Eoth  AREA  and  DMSO  are  pursuing  a  unified  high-level  architecture  for  all  military  simulation. 
Multiple  ARPA-funded  efforts,  the  NSS,  the  JTF-ATD,  Argonne  National  Laboratory’s  Dynamic 
Environmental  Effects  Model  (DEEM),  and  several  others  are  participating  in  developing  this  archi¬ 
tecture.  JWSOL  also  addresses  the  needs  of  these  projected  high-level  architectures.  Since  most  of 
the  candidates  follow  current  best  practice  in  object-oriented  operating  systems  development,  it  is 
possible  to  project  a  generic  version  of  what  might  emerge  from  the  current  effort.  Figure  8  shows  a 
generic  version  of  how  a  unified  high-level  architecture  is  likely  to  appear. 

JWSOL  resides  in  three  places  within  the  architecture,  all  in  the  server  layer.  First,  by  its  inherent 
design  it  can  comprise  a  portion  of  the  Object  Repository.  Second,  it  is  an  integral  part  of  the  Model 
Request  Eroker  (described  in  section  6.2).  Third,  it  is  potentially  part  of  a  “front-end”  to  the  Data 
Server.  At  the  analysis  and  design  levels,  no  changes  are  necessary  to  the  JWSOL  to  satisfy  all  three 
of  these  server  requirements. 
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Architecture  Lavers 


Figure  8.  Analgram  of  elements  expected  to  be  present  in  the  DoD  Unified  High-Level 
Architecture.  JWSOL  could  contribute  to  the  Object  Repository,  the  Data  Server,  and  the  Model 
Request  Broker.  This  illustration  borrows  heavily  from  the  layered  architecture  of  the  JTF-ATD. 
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6.  TECHNOLOGY 


This  section: 

•  Discusses  the  advantages  of  object  technology  (OT), 

•  Very  briefly  presents  its  defining  features, 

•  Introduces  the  notation  used, 

•  Discusses  model  interoperation  and  the  role  of  JWSOL  in  supporting  it, 

•  Explains  some  of  the  problems  of  classification  that  make  creating  an  object-oriented  taxon¬ 
omy  fundamentally  difficult. 

6.1  OBJECT  TECHNOLOGY 

Object-oriented  analysis,  design,  and  programming  (collectively  OT)  rest  on  five  pillars:  abstrac¬ 
tion,  hierarchy,  inheritance,  encapsulation,  and  polymorphism. 

Abstraction  is  the  separation  and  articulation  of  those  elements  or  aspects  crucial  to  the  identity  of 
a  thing  from  those  that  can  be  ignored,  at  a  particular  level  of  discourse.  OT  expresses  abstraction  in 
three  ways:  with  hierarchy,  inheritance,  and  encapsulation. 

Hierarchy  is  the  arrangement  of  parts  into  a  whole,  with  some  form  of  ordering  from  top  to  bot¬ 
tom.  OT  uses  two  kinds  of  hierarchy,  generalization/specialization  and  whole/part.  These  are  some¬ 
times  called  taxonomic  and  partonomic.  In  the  generalization/specialization  hierarchy,  the  basic  rela¬ 
tion  is  “is-a”;  an  element  lower  in  the  hierarchy  “is  an”  instance  of  one  higher  in  the  hierarchy.  For 
example,  a  fighter  is  an  aircraft;  a  tank  is  a  vehicle;  an  officer  is  a  person.  Note  that  “is-a”  applies 
both  to  class  specialization  (a  fighter  is  an  aircraft)  and  to  generic/individual  mapping  (Frig  is  a  Frig¬ 
ate).  In  the  whole/part  hierarchy,  both  composition  (is-made-up-of)  and  association  (is-a-member-of) 
are  represented. 

Inheritance  provides  elision.  Elements  common  to  several  different  program  elements  can  be 
defined  once,  in  one  place,  at  the  right  level  of  abstraction,  and  reused  at  successively  finer  degrees 
of  resolution.  Inheritance  can  increase  the  comprehensibility  of  complex  programs  by  isolating  char¬ 
acteristics  and  behavior  at  levels  appropriate  to  the  subject  matter  and  at  levels  of  abstraction  relevant 
to  the  programmers  and  users  of  the  individual  system.  Inheritance  works  only  from  the  more  gen¬ 
eral  parent  class  downward  to  the  more  specialized  child  classes. 

Inheritance  applies  to  both  attributes  and  methods.  Attribute  values  can  be  overwritten  or  special¬ 
ized  as  one  moves  deeper  into  a  class  structure;  so  can  methods.  For  example,  some  object-oriented 
languages  provide  “before”  and  “after”  method  types.  When  a  message  is  received,  triggering  the 
specialized  method,  the  before  method  is  invoked,  then  the  inherited  method,  then  the  after  method. 

Encapsulation  is  the  combination  of  data  and  procedures  into  a  whole,  with  a  well-defined  and 
rigorously  enforced  interface.  Encapsulation  promotes  modularity  and  independence  from  particular 
implementations.  With  encapsulation,  the  interior  of  an  encapsulated  object  can  be  completely 
rewritten,  and  as  long  as  the  interactions  promised  by  the  interface  remain  intact,  no  change  is 
required  of  the  surrounding  objects. 

Finally,  polymorphism  (“many-formed-ness”)  provides  dynamic  binding  and  multiple  receipt  for 
object  communications.  This  means  it  is  not  a  sending  object’s  obligation  to  know  either  exactly  to 
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whom  it  is  sending,  nor  exactly  how  its  message  will  be  processed.  This  powerfully  supports  object 
independence,  both  conceptually  and  in  terms  of  implementations  and  run-time  instantiations. 


6.1.1  OT  Advantages 

OT  offers  significant  advantages  for  defense  modeling  and  simulation  as  well  as  decision  support 
and  situation  development  applications.  OT  simulation  of  warfare  requires  decomposing  the  warfare 
domain  into  objects,  in  contrast  to  traditional  analysis  of  warfare  domain  models  as  processes.  Using 
abstraction  permits  the  OT  analyst  to  focus  on  what  an  object  is  and  does,  before  (and  independent 
of)  any  implementation  decisions.  This  permits  the  same  objects,  and  models  composed  of  them,  to 
be  used  for  subject  matter  analysis,  high-level  software  design,  program  structure,  database  structure, 
and  documentation,  while  deferring  programming  details  until  the  final  stage  of  development.  It  is 
also  this  aspect  of  OT  that  makes  a  powerful  automation  tool  in  other  than  M&S  implementations. 

OT  also  permits  the  development  of  flexible  and  modular  objects.  For  example,  if  an  application 
needed  to  have  DIS  compatibility,  inheritance  could  be  used  without  changing  the  core  object  (e.g.,  a 
tank  is  a  tank  in  the  object  model,  but  can  be  a  DIS  tank  in  a  simulation  with  no  change  because  it 
can  inherit  that  capability  from  the  DIS  class  object).  That  same  tank  object  could  become  an  Inter¬ 
vehicle  Information  System  (IVIS)  object  for  use  in  or  sustainment  applications. 

As  a  DoD  modeling  and  simulation  methodology,  OT  provides  an  opportunity  to  build  more  com¬ 
patible  and  interoperable  software  applications.  Access  to  a  sound  set  of  base  warfare  objects  means 
considerably  less  work  will  be  required  to  build  applications.  This  supports  the  application  of  such 
techniques  as  Rapid  Application  Development  (RAD)  and  means  that  project  teams  can  be  smaller. 
When  these  two  fectors  are  considered  together  (object  reuse  and  smaller  project  teams),  very  large 
gains  in  productivity  are  possible. 

6.1.2  OT  Methodologies  and  Notation 

Several  methodologies  are  being  used  within  the  OT  community,  including  Rumbaugh,  Booch, 
Wirfs-Brock,  Martin/Odell,  CoadTfourdon,  Shlaer/Mellor,  and  Jacobson.  While  there  are  differences 
among  the  methods,  Rumbaugh’s  comment  that  they  are  all  much  more  similar  to  one  another  than 
any  are  to  traditional  approaches  seems  to  reflect  a  consensus  within  the  OT  community. 

A  modified  Rumbaugh  approach  was  chosen  because  of  its  expressive  power  and  clarity.  Figures  9 
through  14  are  derived  from  Rumbaugh.  This  modified  notation  is  introduced  here  to  make  the  taxo¬ 
nomic  diagrams  given  in  appendix  A  understandable. 

Throughout  this  section,  “class”  is  used  to  denote  the  structural  and  algorithmic  representation  of  a 
concept  or  thing.  “Object”  is  used  only  to  refer  to  an  instance,  actually  instantiated  on  a  computer,  of 
a  class.  For  example,  “F-16E”  would  have  the  attributes  and  methods  needed  to  define  an  F-16. 
“F-16E_AF1234A”  could  then  be  a  particular  instance  of  an  F-16E  instantiated  within  a  running 
simulation.  The  former,  F-16E,  would  be  a  class;  the  latter,  F-16E_AF1234A,  would  be  an  object. 

Rumbaugh  et  al.  advocates  the  notation  shown  in  figures  9  through  14.  Class  (figure  9)  has  three 
parts.  The  top  is  reserved  for  the  class  name.  The  middle  lists  attributes.  These  are  named  in  the 
JWSOL  taxonomy;  in  some  cases,  additional  information  is  specified,  e.g.,  data  type,  range,  legal 
values,  etc.  The  bottom  section  lists  methods  (called  “virtual  functions”  in  C++). 
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CLASS  NAME 


attribute 

attribute:  data_type 
attribute:  dta_type :  int_vaiue 


operation 

operation(orgjist) :  return_type 


Figure  9.  Classes  have  names, 
attributes,  and  methods. 

Inheritance  is  shown  by  a  triangle  (figure  10).  Conventionally,  inheritance  is  shown  with  the  more 
general  class  toward  the  top  of  the  diagram  and  the  more  specialized  class  (es)  toward  the  bottom. 
Alternately,  the  generalization  may  be  toward  the  left  and  the  specializations  toward  the  right.  Multi¬ 
ple  inheritance  is  shown  by  connecting  two  or  more  general  classes  with  a  specialization  class. 


Figure  10.  Inheritance  is  marked  by  a  triangle. 


Association  is  shown  in  four  related  ways,  depending  on  the  complexity  of  the  association  that 
needs  to  be  represented  (figure  11).  The  simplest  form  is  a  labeled  line  linking  two  classes.  If  the 
association  is  qualified,  then  a  small  box  extends  out  from  the  qualifying  class  naming  the  qualifica¬ 
tion  factor.  For  associations  that  call  for  more  elaboration,  there  can  be  association  classes  holding 
either  link  attributes  or  link  attributes  and  methods.  These  can  be  used  to  show  complex  relations, 
e.g.,  of  a  commander  to  his  or  her  unit  and  assignment. 
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AssodaSon  Name 


Class-1 

role-1  role-2 

Association  Name 


Association  Name 


Figure  11 .  Associations  can  be  simple  or  can  be 
arbitrarily  complex  classes  in  themselves. 

Aggregation  is  shown  by  a  diamond  (figure  12).  Aggregation  (also  called  composition)  is  used  to 
show  how  components  fit  together  into  a  whole.  For  instance,  a  Car  class  might  have  a  Power  Train, 
a  Body,  and  a  Make/Model  through  aggregation.  Aggregates  can  be  nested  to  whatever  depth  is 
appropriate  to  the  subject  matter.  There  is  no  inheritance  through  aggregation.  Assuming  that  an 
assembly  class  inherits  characteristics  of  its  aggregated  parts,  or  the  inverse,  that  the  parts  inherit 
from  the  container,  are  among  the  most  common  errors  made  by  people  learning  OT. 
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Figure  12.  Aggregation  is  used  to  show  assembly  classes  that  are  built 
with  their  aggregates. 

Cardinality  of  association  or  aggregation  allows  the  analyst  or  designer  to  specify  exactly  how 
many  instances  of  the  subclass  should  be  connected  to  the  parent  class  (figure  13).  This  can  be  used 
to  distinguish  necessary  and  optional  connections.  Ordered  connections  can  also  be  shown,  e.g.,  cars 
with  either  two  or  four  doors. 


Figure  13.  The  cardinality  of  a  connection 
can  be  specified. 


Abstract  classes  are  those  whose  instances  are  also  classes  (figure  14).  These  are  useful  to  gather 
fairly  high-level  characteristics  together  representationally,  without  the  specificity  required  for  a 
class  that  has  actual  instances.  “Platform”  is  an  example  of  an  abstract  class.  To  instantiate  a  plat¬ 
form,  one  must  move  deeper  into  the  hierarchy  to  specify  what  kind  of  platform  is  desired. 
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Superclass 


operation  (abstract) 


Subclass-1 

Subclass-2 

operation 

operation 

Class  Name 


Sattribute 


Soperation 


Figure  14.  Abstract  superclasses  are  those  whose 
instances  are  classes. 

Class  attributes  are  attributes  that  belong  to  a  class  rather  than  to  any  particular  instance  of  a  class. 
For  example,  one  might  want  to  record  the  number  of  submarines  in  a  particular  model.  That 
information  properly  belongs  to  the  class  Submarine  rather  than  to  any  particular  instance  of  Subma¬ 
rine.  A  class  attribute  is  one  way  to  manage  that  information. 

The  JWSOL  program  also  uses  Harel  state  transition  diagrams  (figure  15).  Both  Rumbaugh  and 
Booch  recommend  them.  They  are  straightforward;  software  engineers  can  use  them  immediately, 
and  SMEs  have  little  trouble  understanding  them. 

Two  aspects  distinguish  Harel  diagrams  from  other  state  transition  diagramming  approaches.  First, 
Harel  distinguishes  actions  from  events.  Actions  take  place  within  a  state;  for  example,  “being  in 
transit”  might  be  a  state  for  an  Army  platoon.  Among  the  actions  that  could  be  represented  within 
this  state  would  be  consumption  of  petroleum,  oil,  and  lubricants  (POL),  food,  spare  parts,  etc. 
Events  take  place  at  transition  boundaries.  The  platoon’s  arrival  at  an  assembly  area  would  be  an 
example. 

Second,  Harel  diagrams  can  be  nested  to  recursively  show  different  levels  of  events  and  actions. 
The  disadvantage  of  this  is  that  the  specific  connection  between  the  state  transition  diagram  and  the 
class(es)  to  which  it  applies  can  be  obscured.  The  benefit  is  that  a  very  wide  range  of  behaviors  can 
be  economically  and  consistently  represented. 

6.1.3  Single  and  Multiple  Inheritance 

There  are  two  kinds  of  inheritance  in  object  systems:  single  inheritance  and  multiple  inheritance. 
In  single  inheritance,  a  strict  (tree)  hierarchy  is  maintained.  In  multiple  inheritance,  an  inclusive  (lat¬ 
tice)  hierarchy  is  allowed. 
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Entry,  exit,  and  internal  actions 

^  State-1  ^ 

do:  acthnty-l  event-1  /  action-1 

entry /aclion-2  - 

exit /action-3 
V  event /action-4  y 


Simple  state  diagram  with  operations 


Concurrent  states 

Superstate-1  \ 


Generalization  in  state  diagrams 


(Example  from  Rumbaugh) 


Legend 

State  (with  label) 

^  start 

End 

^  Connector 

(  Label  ) 

V  J 

Figure  15.  Hare!  state  transition  diagrams  allow 
sophisticated  representation. 


Multiple  inheritance  adheres  more  closely  to  the  “natural”  OT  approach  taken  in  JWSOL.  For 
example,  a  stereo  system  is  (inherits  characteristics  and  behaviors  from)  an  appliance,  a  luxury  item, 
and  a  fragile  commodity.  A  truffle  is  also  a  fragile  commodity,  a  luxury  item,  and,  unlike  stereos,  a 
perishable  commodity.  In  a  multiple  inheritance  system,  base  classes  for  Appliance,  Luxuryltem, 
FragileCommodity,  and  PerishableCommodity  could  be  built.  Both  StereoSystems  and  Truffles,  as 
well  as  Refrigerators,  Eggs,  and  ChinaTeacup  would  then  “fall  out”  of  the  base  classes. 


43 


In  a  single  inheritance  system,  a  larger  number  of  more  specialized  classes  must  be  created  to 
achieve  the  same  representation.  For  example,  for  a  StereoSystem  to  have  the  desired  characteristics, 
a  class,  FragileAppliances,  or  perhaps  even  FragileLuxury Appliances,  would  need  to  be  created.  The 
attributes  that  characterize  fragility  would  need  to  be  duplicated  for  each  entity  to  which  they  might 
apply  (e.g.,  FragileGroceries,  FragileDishes). 

Delegation  is  a  method  used  in  some  single-inheritance,  object-oriented  programming  languages  to 
reduce  this  class  proliferation.  Using  delegation,  a  class  can  assign  the  handling  of  specified  mes¬ 
sages  to  another  class.  For  example,  a  StereoSystem  might  delegate  messages  or  behaviors  relevant 
to  luxury  to  a  Luxuryltem  object.  Delegation  is  formally  equivalent  to  multiple  inheritance  but  is 
much  more  difficult  to  administer  during  implementation. 

Factors  in  favor  of  single  inheritance  include  the  following; 

•  Many  people  find  it  easier  to  understand. 

•  It  is  easier  to  optimize  computationally  for  memory  management. 

•  Systems  built  with  it  can  be  easier  to  maintain,  although  this  is  highly  sensitive  both  to  the 
design  and  construction  of  the  system  and  especially  to  the  subject  matter  the  system  models. 

However,  multiple  inheritance  corresponds  much  more  directly  to  normal  formation  and  use  of 
concepts.  For  instance,  in  JWSOL  a  river  may  be  a  boundary  from  one  perspective,  a  source  of  water 
from  another,  an  obstacle  from  a  third,  and  a  means  of  transportation  from  a  fourth.  Each  of  these 
can  and  should  be  included.  Multiple  inheritance  is  the  easiest  way  to  represent  these  highly  complex 
battlefield  relationships  and  perspectives. 

Note  that  this  is  a  generic  characteristic  of  any  generally  accepted  class  taxonomy.  If,  as  seems 
possible,  multiple  domain-sensitive  taxonomies  evolve  (e.g.,  JWSOL  for  theater  modeling,  JTF— 
ATD  Schema  for  planning  and  for  finer-grained  models,  etc.),  then  common  meeting  points  and 
shared  objects  would  achieve  this  objective  while  taking  advantage  of  the  increased  power  more 
focused  taxonomies  can  provide. 

6.2  INTEROPERATION  AND  OT  MODELING 

JWSOL  could  potentially  support  interoperability  in  three  ways. 

The  first  is  the  simplest;  new  models  and  simulations  built  using  JWSOL  objects  will  be  able  to 
interoperate  directly.  Because  there  will  be  a  set  of  consistent  common  interfaces,  direct  object-to- 
object  interactions  within  the  application  are  both  possible  and  natural. 

If  models  are  running  on  separate  machines,  an  object  request  broker  (ORB)  would  be  necessary. 
However,  there  are  increasing  numbers  of  these  on  the  market,  and  distributed  operating  systems  like 
Cronus  have  been  in  use  in  military  applications  for  some  time. 

The  versatility  of  this  approach  is  important.  Because  of  it,  independent  modeling  groups, 
associated  with  completely  different  organizations,  can  develop  models  with  a  reasonable  degree  of 
confidence  that  they  will  be  interoperable  at  multiple  levels  (i.e.,  entity,  plus  above  and  below  entity) 
once  they  are  done. 

Second,  JWSOL  could  be  used  as  a  mediator  between  new  and  legacy  models.  This  is  dependent 
on  work  currently  being  explored  in  the  Navy  Simulation  System  (NSS)  architecture,  that  is,  the 
development  of  a  model  request  broker  (MRB).  Analogous  to  an  ORB,  the  MRB  will  manage  model 
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interactions  across  workspaces,  nodes,  and  platforms.  JWSOL  will  then  provide  a  part  of  the  model- 
level  equivalent  of  CORBA’s  Interface  Definition  Language  (IDL),  that  is,  a  model  interaction  defi¬ 
nition  language.  Following  this  development  approach,  legacy  models  will  not  have  to  be  directly 
altered  to  interoperate  with  new  OT  models.  Rather,  a  model  request/model  service  interface  can  be 
built  using  JWSOL  (and  possibly  other)  object  definitions.  Once  again,  interoperability  will  be 
achieved  at  low  cost. 

Third,  JWSOL  could  use  the  MRB  to  mediate  between  legacy  models.  In  this  case,  both  legacy 
models  will  need  a  common-domain-object-based  interface.  If  an  MRB  is  achieved,  interoperation 
can  be  transparent  to  the  base  legacy  system.  Given  the  current  investment,  this  is  extremely  appeal¬ 
ing. 


6.3  CLASSIFICATION 

Some  of  the  problems  that  make  creating  an  object-oriented  taxonomy  difficult  are  discussed  here. 
A  taxonomy  is: 

1.  The  classification  of  organisms  in  an  ordered  system  that  indicates  natural  relationships. 

2.  The  science,  laws,  or  principles  of  classification;  systematics. 

3.  Division  into  ordered  groups  or  categories  [2]. 

The  third  definition  applies,  but  it  is  briefly  considered  as  the  origin  of  taxonomic  classification 
indicated  by  the  first  two.  Historically,  natural  taxonomy  began  as  a  top-down  discipline.  The  top- 
down  approach  starts  with  a  category — ^feline,  for  example — and  then  selects  and  rejects  according  to 
apparent  category  matching.  An  alternate  approach,  bottom-up  classification,  was  first  articulated  in 
the  last  third  of  the  18th  century  and  was  argued  forcefully  by  Darwin  (Chap.  13,  Origin  of  Species). 
Darwin  won;  all  current  arguments  in  biology  about  classification  are  about  variations  on  the 
bottom-up  approach.  Top-down  “classification”  is  now  regarded  not  as  classification  at  all,  only 
identification  [6].  The  point:  almost  all  beginning  taxonomists  tend  to  classify  top-down.  In  JWSOL, 
a  conscious  effort  was  made  to  work  bottom-up,  starting  with  the  most  basic  elements  at  the  level  of 
focus  (theater)  and  moving  up  in  abstraction  only  as  the  content  demanded. 

A  related  error  is  to  confuse  subject  areas  with  classes  [3].  For  example,  in  modem  programs,  sub¬ 
stantial  work  goes  into  human-computer  interation  (HCI).  This  is  an  important  subject  area,  and  it  is 
entirely  reasonable  (from  a  software  engineering  perspective)  to  group  all  of  the  elements  that  com¬ 
prise  the  HCI  into  a  distinct  subsystem.  However,  it  is  not  a  class.  Other  than  being  “part  of  HCI,” 
what  common  attributes  do  a  window  redrawing  routine  and  a  keyboard  input  buffer  have  in  com¬ 
mon?  Just  because  one  might  casually  “class”  all  of  the  HCI  components  together  does  not  mean 
they  are  a  proper  OT  class. 

6.3.1  Ontological  and  Epistemological  Issues  in  Classification 

Ontology  deals  with  “the  nature  of  being,”  which  may  sound  far  removed  from  the  pragmatic  need 
to  get  things  done.  It  is  not.  It  has  been  repeatedly  (and  very  expensively)  shown  that  without  careful 
examination  of  the  ontological  foundations  of  a  particular  domain,  well-intentioned,  energetic  people 
can  get  hopelessly  mired  in  confusion  and  wasted  effort.  If  you  want  to  get  where  you  are  going,  it  is 
a  good  idea  to  know  where  you  are  starting  from.  And  that  means  knowing  ontological  foundations. 

Epistemology  is  the  nature  of  knowledge,  its  presuppositions  and  foundations,  and  its  extent  and 
validity.  Like  ontology,  some  epistemology  is  good  to  have  because  it  allows  a  more  realistic  assess¬ 
ment  of  the  problems  of  taxonomy-building  and  the  validity  of  the  product. 
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The  following  paragraphs  describe  the  fundamental  ontological  problem,  review  some  epistemo¬ 
logical  problems,  and  then  describe  the  simple  but  powerful  ontology  used  to  organize  the  taxonomy. 

First,  ontologies  are  human  constructions,  and  they  vary  from  domain  to  domain.  Lehrer  [8],  fol¬ 
lowing  Perkins  [10],  describes  four  interrelated  features  of  knowledge— the  first  two  are  ontological 
(the  second  two  are  epistemological  and  will  be  covered  shortly): 

•  Knowledge  is  constructed  pragmatically,  incorporating  human  purpose  to  serve  human  ends. 

•  Knowledge  is  structured.  Purpose  and  structure  are  interwoven;  structures  serve  purposes. 

The  implication  is  that  perspective  is  intrinsic  to  any  ontology.  To  make  this  more  concrete,  put 
yourself  in  the  role  of  an  SME  and  think  about  how  you  would  decide  whether  two  classes  should  be 
on  the  same  level  of  abstraction.  For  most  people,  the  instinct  is  to  place  things  with  relatively  equal 
importance  to  the  domain  (relative  to  significant  events  and  actions)  at  the  same  level.  This 
constrasts  with,  say,  examining  the  relative  complexity  of  items  as  reflected  in  their  intrinsic  attrib¬ 
utes.  But  the  idea  of  “intrinsic  attributes”  is  thorny.  How  would  you  decide,  and  by  what  criteria, 
which  attributes,  at  what  level  of  representation,  are  both  intrinsic  and  germane  for  a  given  subject 
area?  A  chemist  and  a  logistics  planner  are  not  likely  to  identify  the  same  set.  Attributes  are  selected 
as  relevant  according  to  our  goals.  No  goals,  no  attribute  selection  criteria;  therefore  no  taxonomy. 
With  goals,  we  get  a  taxonomy,  but  we  also  get  a  perspective.  The  ontological  message:  perspective 
is  fundamental,  not  accidental. 

Having  to  embody  a  perspective  is  not  a  problem  for  highly  focused,  narrow  user-base  ontologies. 
In  fact,  it  is  a  source  of  strength  and  economy  of  representation.  However,  JWSOL  is  intended  to 
support  a  wide  range  of  users,  with  a  wide  range  of  views. 

Before  stating  the  ontology,  one  needs  to  look  at  the  fundamental  epistemological  problem:  the 
world  is  not  made  up  of  ideal  categories.  There  typically  is  not  a  single,  pure,  knowable  identity 
for  any  given  thing.  To  understand  this,  here  are  Lehrer’s  second  two  points: 

•  One’s  knowledge  includes  models  or  cases  that  exemplify  its  structure.  This  enables  commu¬ 
nication,  development  of  mental  models,  and  reasoning. 

•  Knowledge  should  include  some  means  of  developing  and  evaluating  arguments  (i.e.,  should 
contain  some  way  to  develop  validation  criteria). 

When  the  current  set  of  models  and  cases  is  unconsciously  generalized  from  experience,  the  true 
nature  of  a  class  is  obtained.  Evidence  from  cognitive  psychology,  especially  the  work  of  Elanor 
Rosch  [summarized  in  7],  suggests  that  the  “true”  nature  of  a  class  is  a  mental  construction.  For 
example,  everyone  knows  what  a  bird  is.  But  which  is  more  “birdlike,”  a  robin  or  a  turkey?  A  finch 
or  an  ostrich?  When  people  are  tested  for  recognition  of  “birds,”  they  are  significantly  faster  at  iden¬ 
tifying  robins  and  finches  than  turkeys  and  ostriches. 

Everyone  knows  there  are  no  “birds”  out  there,  just  specific  individual  birds  that  humans  find  it 
convenient  to  classify  together.  The  important  point  is  that  in  this  classification  of  natural  kinds, 
classification  is  done  by  prototype,  not  by  the  logician’s  necessary  and  sufficient  conditions.  Place¬ 
ment  of  any  individual  in  a  class  involves  judgment,  not  simply  mechanical  sorting.* 

This  is  the  epistemological  side  of  the  ontological  problem.  There,  it  was  perspective;  here,  it  is 
judgment.  Once  it  is  seen  that  placement  of  individual  examples  into  classes  is  essentially  (and  not 

*  The  judgment  can  get  arbitrarily  complex.  If  Fido  loses  a  leg  in  a  car  accident,  he  is  a  three-legged  individual,  but  he 
is  still  a  dog,  and  therefore  is  a  four-legged  mammal. 
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accidentally,  provisionally,  or  artifactually)  a  matter  of  judgment,  then  the  taxonomist  is  obligated  to 
justify  that  judgment. 

One  fundamental  problem  with  taxonomic  classification  remains — namely,  how  are  you  classify¬ 
ing?  By  function?  By  attributes?  By  probable  or  possible  consequences?  By  actions?  In  OT  writing, 
there  is  an  insistence  on  preference  for  attributes,  especially  over  functions  (which  are  more  promi¬ 
nent  in  traditional  software  design).  This  sounds  reasonable,  but  it  is  not  always  a  clear-cut  distinc¬ 
tion.  Function  influences  which  attributes  are  important  or,  in  the  case  of  manufactured  items,  even 
what  the  attributes  are.  As  seen  above,  purpose  and  structure  are  interwoven.  So,  the  distinction 
between  what  something  is  and  what  it  does  is  valuable  and  rightly  emphasized  by  OT  authors,  but  it 
is  far  from  definitive. 

Figure  16  shows  the  JWSOL  ontology.  The  top  row  shows  the  basic  organizing  perspectives.  The 
middle  row  shows  the  drivers  for  evaluation,  that  is,  for  understanding  the  meaning  of  the  current 
situation.  The  third  row  shows  the  elements  that  evaluation  is  based  on.  The  overall  picture  shown  in 
the  executive  summary  (figure  E-1)  falls  out  of  this  ontology. 


EVENTS 

AGENTS 

OBJECTS 

Figure  16.  JWSOL  ontology  showing  organizing  perspectives,  evaluation  drivers, 
and  evaluation  elements. 
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7.  TAXONOMY 


This  section  presents  the  JWSOL  taxonomy.  The  charts  illustrating  the  hierarchical  relationships 
and  text  describing  the  rationale  for  the  structure  are  provided.  Additional  details  on  attributes  and 
methods  are  included  in  appendix  A. 

7.1  HIGH-LEVEL  OVERVIEW 

The  discussion  of  ontology  (section  6.3)  described  the  use  of  an  Agent/Object/Event  paradigm  for 
taxonomic  classification.  This  section  shows  and  discusses  each  of  the  top-level  elements,  along  with 
discussion  of  their  relationships. 

The  term  “Physical”  rather  than  “Object”  is  used  in  this  section.  All  of  the  elements  discussed  in 
the  taxonomy  are  potential  objects  in  the  OT  sense.  Using  Object  for  just  one  subtree  invites  confu¬ 
sion. 

7.1 .1  Physical 

Physical  is  what  people  normally  associate  with  “objects” — ships,  boats,  planes,  communications 
equipment,  etc.  The  JWSOL  taxonomy  also  includes  a  broad  class  of  environmental  elements  within 
Physical. 

7.1.2  Event 

An  Event  is  something  that  happens.  In  the  past,  events  were  predominately  represented  within 
state  transition  diagrams.  They  are  still  represented  that  way;  however,  recent  thinking,  e.g.,  Martin 
and  Odell  [9],  has  suggested  elevating  them  to  the  status  of  classes.  This  makes  sense.  Many  events 
have  natural  subclassing — missions  are  an  obvious  military  example. 

7.1.3  Agent 

“Agency”  is  the  core  unifying  idea  linking  people  and  organizations.  Both  can  properly  be  said  to 
have  goals,  desires,  motivation,  intentions,  and  plans.  Agents  initiate  actions  to  pursue  goals.  If  you 
can  appropriately  think  about  it  as  having  intentions,  it  is  an  Agent  [4]. 

Since  reasoning  by  cause  is  far  more  important  than  other  kinds  of  reasoning  [11],  being  able  to 
model  humans  and  organizations  is  critical.  We  universally  posit  goals  and  motivation  to  reason 
about  causes  of  events. 

The  JWSOL  taxonomy  has  two  broad  cases  of  Agent,  Human  and  Organization  (see  section  7.4). 
Their  relationship,  i.e.,  aspects  of  human  roles  that  lie  essentially  in  a  person’s  relationship  to  an 
organization,  are  modeled  via  an  association  class. 

Organizations  are  modeled  as  structures,  subclassed  shallowly  according  to  predominant  mode  of 
activity.  This  is  possible  because  the  internal  structure  of  Organization  recurs  without  significant 
change  at  multiple  levels. 

Organization  is  intended  to  represent  groups  of  people  acting  together,  “group”  being  arbitrarily 
large  or  small.  It  may  even  be  the  case  that  for  some  modeling  or  planning  needs  the  group  may  con¬ 
sist  of  a  single  individual.  For  example,  it  may  be  preferable  to  model  the  truck  bombing  of  the 
Marine  compound  in  Beirut  as  being  performed  by  the  Hez’bollah  even  though  a  single  person  per¬ 
petrated  it. 
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Command  and  Control  is  the  “glue”  that  combines  the  Physical,  the  Event,  and  the  Agent.  In  a 
military  context,  it  is  the  knowledge  infrastructure  that  is  learned  and  handed  down  through  genera¬ 
tions  of  experience  from  leader  to  leader,  through  schooling  and  training  as  well  as  through  standard 
procedures  and  policy.  It  is  the  decision-making  policy,  the  physical  decision-making  chain  from  top 
to  bottom,  and  the  feedback  that  goes  back  from  the  bottom  to  the  top.  It  includes  the  people,  chain 
of  command,  the  physical  communication  infrastructure,  and  historic  events  that  have  framed  deci¬ 
sion  making  by  leaders.  It  is  the  appropriate  use  of  centralized  and  decentralized  control,  where 
appropriate,  that  permits  the  vast,  both  in  size  of  force  and  sphere  of  influence,  U.S.  political/military 
team  to  participate  effectively  in  world  current  affairs. 

The  root  of  the  top  three  superclasses,  Agent/Physical/Event,  has  a  ternary  association  class  called 
Command  and  Control  that  relates  the  three  classes  at  the  top  of  the  JWSOL  taxonomy  (figure  17). 


Figure  17.  JWSOL  taxonomy. 


7.2  PHYSICAL  SUBTREE 

The  physical  subtree  has  eight  classes  of  materiel  warfighting  objects,  plus  the  environmental 
objects  Natural  and  Artificial  (figure  18).  Although  most  of  the  classes  obviously  fit  within  this  sub¬ 
tree,  the  rationale  for  inclusion  of  others  is  not  so  self-evident.  For  example,  sensors,  communica¬ 
tions,  and  countermeasures  are  most  often  thought  of  as  capabilities  or  parts  of  a  land  vehicle,  air¬ 
craft,  or  vessel.  But  they  are  physical  objects  that  have  common  attributes  when  included  on  a 
platform,  as  well  as  specific  attributes  depending  on  its  type  of  employment  (i.e.,  air,  land,  or  sea). 

7.2.1  Materiel  Warfighting  Objects 

Communications  has  two  subclasses.  Equipment  and  Networks,  which  are  composed  of  both 
nodes  and  links  (figure  19).  The  links  consist  of  courier,  relay,  and  line,  and  the  nodes  consist  of  tele¬ 
phones,  computer  equipment,  and  different  types  of  radios. 

Aircraft  has  two  major  subclasses,  Fighting  and  Transport/Payload  (figure  20);  this  operational 
mission  view  was  chosen  for  the  classification  structure.  Fighting  is  further  broken  into  Attack, 
Fighter,  Bomber,  EW,  C^,  Reconnaissance,  and  ASW.  The  Transport/Payload  subclass  consists  of 
aircraft  supporting  the  functional  mission  areas  of  Supply,  Aeromedical  Evacuation,  Personnel,  Spe¬ 
cial  Ops,  Combat  Rescue,  and  Air  Refueling. 
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s,  command  and  control. 


Countermeasure  has  five  major  subclasses:  Prairie  Masker,  Visual/Optical,  Decoys,  Chaff,  and 
Jammers  (ECM)  (figure  21). 


Figure  21.  Countermeasure  class. 


Land  Vehicle  has  three  major  subclasses:  Fighting,  Engineering,  and  Transport  (figure  22).  Land 
vehicles,  like  aircraft  and  vessels,  have  an  aggregated  and  associated  organization,  weapon  system, 
communications,  command  and  control,  sensors,  crew,  and  countermeasures. 
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Satellite  is  a  platform  that  has  associations  that  contain  Communications  and  Sensors  (figure  23). 


Figure  23.  Satellite  class. 

Vessel  has  three  major  subclasses,  Fighting,  Support,  and  Transport  (figure  24).  Vessels  have  an 
aggregated  and  associated  organization,  weapon  system,  communications,  command  and  control, 
sensors,  crew,  and  countermeasures. 

Weapon  System  has  five  subclasses,  Missile/Rocket,  Bomb,  Gun,  Mine,  and  Torpedo  (figure  25). 

There  is  an  explosive  payload  association  between  the  ASROC  class  and  the  Bomb  and  Torpedo 
classes  (figure  26)  for  the  appropriate  payload. 

Sensor  has  two  major  subclasses:  Active  and  Passive  (figure  27). 

7.2.2  Environment 

The  JWSOL  Environment  taxonomy  subtree  follows  the  Dynamic  Environmental  Effects  Model 
(DEEM)  approach  of  providing  much  more  explicit  and  complete  modeling  than  usual.  This  is 
important  for  three  reasons. 

First,  increasing  computational  power  and  growth  in  distributed  computing  makes  it  possible  to 
model  the  environment  with  greater  resolution  and  accuracy  than  has  been  true  in  the  past.  This  will 
lead  to  more  consistent  models  and  other  applications  of  the  taxonomic  objects.  Many  legacy  sys¬ 
tems  model  devices  and  platforms  in  excruciating  detail,  but  then  model  their  operating  environment 
in  the  most  trivial  way,  except  in  some  very-fine-grained  one-on-one  engagements  and  underwater 
models.  This  casts  doubt  on  the  reliability  of  the  models.  JWSOL  will  be  able  to  support  correcting 
this  problem. 

Second,  environmental  concerns  are  increasingly  real  in  military  planning  and  operations.  Recall 
the  smoke  plumes  and  20-mile  oil  slick  resulting  from  Iraq’s  “ecoterrorism”  in  the  Gulf  War.  Or  con¬ 
sider  the  status  of  the  many  nonfunctioning  Russian  nuclear  submarines.  Direct  modeling  of,  and 
planning  regarding,  these  kinds  of  environmental  issues  is  increasingly  important. 

Third,  having  access  to  detailed  environmental  classes  and  objects  makes  adaptation  of  planning 
and  modeling  to  new  operations  faster  and  more  reliable.  Food  delivery  in  Rwanda,  house-to- 
house  fighting  in  Mogadishu,  peacekeeping  in  Haiti:  none  of  these  are  tradiational  applications  of 
computer-based  support  for  modeling,  planning,  or  training. 
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Note:  Vessels  have  aggregated  and  associated  organization, 
weapon  system,  communications,  command  and  control, 
sensors,  crew  and  countermeasures. 


Figure  25.  Weapon  System  class. 


Figure  26.  ASROC  association. 
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Sensor 
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Figure  27.  Sensor  class. 


Figures  28  through  33  show  the  JWSOL  taxonomy  for  the  environment.  Figure  28  shows  a  top- 
level  view  of  the  primary  subclasses  that  make  up  the  JWSOL  environment.  At  the  top-most  level, 
the  environment  is  divided  into  Natural  and  Artificial  classes. 


Figure  28.  Environment  superclass  with  two 
subclasses — Natural  and  Artificial. 

Appendix  A  includes  detailed  Rumbaugh  drawings  of  all  of  the  environment  objects  including 
attributes.  The  level  of  detail  provided  for  the  environment  is  high  and  consistent  with  that  provided 
with  the  other  JWSOL  objects.  For  example,  information  on  the  vegetation  characteristics  of  a  sec¬ 
tion  of  terrain  is  required  to  calculate  the  travel  times  of  a  force  moving  toward  a  given  objective. 
This  kind  of  detail  is  provided  in  the  JWSOL  environment  taxonomy. 

7.2.2.1  Natural  Environment.  Natural  Environment  is  divided  into  two  classes:  Region  and  Non- 
Human  Lifeform.  Regions  are  the  “traditional”  components  of  the  earth-atmosphere  system:  land, 
ocean/sea,  air,  and  space.  Non-Human  Lifeform  is  divided  into  Plant,  Animal,  and  Virus. 

The  Land  taxonomy,  as  shown  in  figure  29,  is  based  on  that  used  by  DEEM.  Land  is  subdivided 
into  Surface  Cover,  Soil  Cover,  Snow  Cover,  Drainage  Cover,  and  Topography  objects.  Surface 
Cover  describes  the  surface  characteristics  of  a  specific  piece  of  land,  and  the  specific  categories  are 
based  on  those  used  in  DMA’s  Interim  Terrain  Data  (ITD)  specification. 

The  Topography  object  describes  any  topographic  feature  that  can  be  found  on  land.  Topography 
is  divided  into  features:  Point  (e.g.,  a  crater).  Line  (e.g.,  a  river  bed),  and  Area  (e.g.,  mountain  range). 
This  taxonomy  is  general  and  avoids  having  to  deal  with  vague  terms  like  “hill.” 

The  Ocean/Sea  object,  also  shown  in  figure  29,  denotes  the  major  oceanic  components  of  the  earth 
and  is  described  in  a  way  similar  to  Land.  (Inland  bodies  of  water  like  the  Great  Lakes,  the  Caspian 
Sea,  etc.,  are  handled  under  the  Open  Water  object  under  the  Land  Region  object.)  There  is  an  object 
to  encompass  the  actual  water,  and  there  are  objects  to  describe  the  sea  bottom  and  littoral  area.  As 
with  the  land,  the  sea  bottom  also  has  a  topography  object  to  describe  the  topographic  features  that 
are  found. 
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Originally,  water  that  would  be  found  on  land,  like  rivers  and  lakes,  was  included  under  a  more 
general  “water”  object.  Later,  these  were  put  under  the  Land  Region  object.  The  reason  is  that  these 
bodies  of  water  are  generally  fed  by  dynamic  hydrological  processes  on  the  land  (e.g.,  runolf)  and 
that  the  spatial  extents  can  be  highly  variable.  For  example,  rivers  can  dry  up  or  they  can  flood. 
Therefore,  although  one  can  identify  a  river  bed  on  a  piece  of  land,  one  cannot  always  be  sure  of 
identifying  the  extent  of  the  water  that  is  flowing  down  the  riverbed. 

To  account  for  this,  a  “nominal”  Open  Water  object  represents  that  portion  of  a  land  surface  “nor¬ 
mally”  covered  by  water.  An  example  would  be  a  river  or  a  small  lake.  Tied  to  this  object  is  another 
object,  the  “nominal”  bottom  object  that  represents  the  river  bed,  for  example,  over  which  the  water 
is  flowing.  The  nominal  bottom  object  has  attributes  like  those  of  an  exposed  soil.  In  a  way  similar  to 
the  Open  Water  object,  there  is  a  snow  (or  ice)  cover  object  that  represents  a  surface  that  would  nor¬ 
mally  be  covered  by  snow  or  ice. 

In  the  “real  world,”  open  water  on  land  and  snow  involves  highly  dynamic  processes  that  can  change 
quickly.  This  object  taxonomy  for  the  environment  is  designed  to  allow  for  these  kinds  of  dynamic 
variations;  i.e.,  rivers  can  dry  up  or  flood. 

The  Air  region  is  simply  divided  into  basic  components  in  the  atmosphere:  gas,  aerosol,  cloud,  and 
precipitation.  Originally,  the  Air  region  was  to  be  divided  into  atmospheric  subregions,  such  as 
boundary  layer,  troposphere,  and  stratosphere,  but  this  was  rejected  for  three  reasons.  First,  this  dif¬ 
ferentiation  might  not  be  understood  by  the  layperson.  Second,  because  these  layers  are  defined  by 
basic  differences  in  the  underlying  physics  of  the  atmosphere,  no  general  boundaries  could  be 
assigned  to  these  layers.  Third,  no  benefit  would  be  gained  for  any  simulation  by  adding  these  layers. 

Figure  30  shows  the  Non-Human  Lifeform  objects.  The  Animal  object  has  three  subclasses:  Pet, 
Wild,  and  Livestock.  These  classes  are  further  subdivided  into  aquatic  and  terrestrial  objects.  The 
Plant  object  is  divided  into  Woody  and  Herbaceous,  which  are  further  subdivided  into  Aquatic  and 
Terrestrial. 

7.2.2.2  Artificial  Environment.  The  Artificial  environment,  shown  in  figure  31,  consists  of  those 
tangible  objects  or  artifacts  built  by  humans.  Examples  are  any  type  of  structure  that  can  be  built. 

The  objects  found  in  the  Artificial  environment  are  related  to  the  Natural  environment  in  that  they 
are  found  in  some  region  of  the  Natural  environment.  The  building  materials  used  in  their  construc¬ 
tion  can  also  be  made  from  components  found  directly  in  the  Natural  environment,  such  as  soil,  as 
well  as  those  that  have  been  processed  from  materials  found  in  the  Natural  environment,  such  as 
wood  or  metal. 

The  Structure  object  describes  any  structure  that  can  be  built.  In  this  version  of  the  JWSOL  taxon¬ 
omy,  the  Structure  object  is  divided  further  into  Building,  Bridge,  Tunnel,  and  Pole/Tower  objects. 
Each  one  of  these  objects  is  then  described  in  terms  of  the  fundamental  components:  Section,  Panel, 
Support,  Trim,  Opening,  and  Membrane.  From  these  components,  any  type  of  structure  can  be  built. 
The  use  of  the  structure  (e.g.,  a  dwelling,  office  building,  etc.),  is  considered  to  be  an  attribute.  This 
approach  has  been  used  successfully  within  the  DEEM  effort  to  incorporate  munitions  effects  against 
buildings  in  an  urban  warfare  simulator. 
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Environment 


Figure  30.  Non-Human  Lifeform  class. 


Figure  31.  Artificial  class  showing  Structure,  Earthwork,  Complex,  and  Built-up 
Area  subclass. 
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The  Earthwork  object  consists  of  any  artificial  feature  built  on  the  land,  such  as  levees,  earthen 
dams,  dikes,  and  trenches.  These  objects  would  be  associated  with  land  features  and  may  appear  as 
either  line  or  point  features  on  a  map.  Each  of  these  objects  is  assumed  to  consist  of  earthen  materi¬ 
als.  For  example,  if  a  trench  had  a  concrete  lining,  the  cut  in  the  soil  would  be  under  the  Earthwork 
class,  while  the  concrete  lining  would  be  described  as  a  structure. 

Complexes  are  described  in  terms  of  their  primary  use,  such  as  industrial  site  or  medical  facility. 
On  a  map,  complexes  would  be  denoted  as  either  point  or  area  features. 

A  complex  would  normally  have  a  series  of  structures  associated  with  it.  The  structures  can  be 
complicated  buildings  that  could  be  found  in  an  industrial  complex,  or  a  simple  parking  lot  that  could 
be  found  at  a  recreational  complex. 

The  Built-up  Area  object  denotes  any  area  where  humans  live.  The  built-up  areas  can  be  classed 
further  in  terms  of  general  demographic  categories,  such  as  rural,  city,  and  town. 

The  Physical  Infrastructure  object,  shown  in  figure  32,  describes  the  objects  that  provide  needed 
services  to  the  environment,  such  as  transportation,  utilities,  and  energy.  The  transportation  infra¬ 
structure  is  described  in  terms  of  rail,  road,  water,  and  air  components.  Each  transportation  compo¬ 
nent  is  described  in  terms  of  a  net,  nodes,  and  links.  The  Utility/Energy  object  is  used  to  describe  the 
networks,  nodes,  and  links  required  for  the  distribution  of  services,  such  as  water,  sewer,  power,  and 
telecommunications.  The  Air  Link  subtree  shown  in  figure  33  has  attributes  and  methods  for  two 
subclasses.  Airway  and  Military  Air  Corridor. 

7.3  EVENT  SUBTREE 

The  Event  Subtree  has  three  primary  objects:  Military  Event,  Civilian  Event,  and  Environmental 
Phenomena,  as  shown  in  figure  34.  The  objects  that  this  subtree  represents  are  temporal.  The 
Engagement  class  of  Military  Event  has  17  subclasses  covering  Air-to-Air  through  Subsurface-to- 
Subsurface  engagements. 

The  Civilian  Event  object  denotes  nonmilitary  occurrences.  Most  of  the  subclasses  are  politically 
or  economically  based. 

The  Environmental  Phenomenon  object  describes  significant  events  that  shape  what  happens. 
Events  have  a  distinct  temporal  and  spatial  nature  in  that  they  occur  over  a  fixed  time  and  occur  at  a 
given  location(s).  Using  this  definition,  the  Environmental  Phenomenon  objects  are  described  in 
terms  of  Biological,  Meteorological,  Geological,  Sociological,  Astronomical,  and  Hydrological,  as 
shown  in  figure  34.  The  spatial  extent  over  which  a  phenomenon  has  no  definitional  limitations 
should  be  noted.  For  example,  a  sunspot  can  result  in  disruption  to  an  entire  telecommunications  net¬ 
work.  (The  spatial  extent  will  be  entirely  driven  by  the  context  of  the  simulation  being  performed.) 

Also,  an  Environmental  Phenomenon  of  a  specific  type  can  spawn  one  or  more  of  another  type.  As 
an  example,  an  undersea  earthquake  (Geological  Environmental  Phenomenon)  can  give  rise  to  a  tsu¬ 
nami  (Hydrological  Environmental  Phenomenon)  that  could  trigger  a  tidal  wave  (Sociological  Envi¬ 
ronmental  Phenomenon)  when  it  reaches  land. 

7.4  AGENT  SUBTREE 

The  Agent  Subtree  has  two  primary  objects.  Human  and  Organization,  shown  in  figure  35.  An 
association  class  called  Role  relates  Human  to  Organization. 
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Figure  32.  Artificial  class  showing  Physical  Infrastructure  subclass. 


Figure  33.  Air  Link  subclass. 


7.4.1  Human  Subclass 

The  Human  subclass  has  attributes  such  as  Profession,  Skill,  Degree  of  Proficiency,  Sex,  Age, 
Language(s),  and  Special  Physical  Characteristics. 


7.4.2  Organization  Subclass 

As  mentioned  above  (section  7.1.3),  organization  is  intended  to  represent  groups  of  people  acting 
together.  “Group”  can  be  arbitrarily  large  or  small.  It  may  even  be  the  case  that  for  some  modeling  or 
planning  needs  the  group  may  consist  of  a  single  individual.  For  example,  it  may  be  preferable  to 
model  the  truck  bombing  of  the  Marine  compound  in  Beirut  as  being  performed  by  the  Hez’bollah, 
even  though  it  was  performed  by  a  single  person.  Organization  has  three  subclasses:  Military  Orga¬ 
nization,  Non-Military  Organization,  and  Crew.  Note  that,  as  currently  conceived,  small  groups  of 
humans,  e.g.,  a  crew,  are  modeled  as  a  subclass  of  Organization,  with  which  individual  Humans  may 
be  associated.  They  are  modeled  by  associating  Human  with  Crew  through  the  Role  relationship. 


7.4.3  Role  Subclass — Human  Subclass  and  Organization  Subclass  Relationship 

People  are  represented  by  the  Human  class  and  participate  in  an  Organization  class.  Role  is  the 
association  that  gives  a  person  a  definition  within  an  organization.  Some  roles  derive  from  the  ability 
of  the  individual  considered  alone.  Doctor,  lawyer,  and  software  engineer  are  examples.  Other  roles 
derive  from  an  individual’s  relationship  to  an  organization  (figure  36).  Speaker  of  the  House  and 
prisoner  are  examples.  A  Human  can  perform  in  many  roles  depending  on  the  situation.  For  exam¬ 
ple,  a  CEO  of  a  Private  Organization,  like  a  company,  will  be  in  the  leadership  role  for  that  Private 
Organization — Human  Association.  The  same  CEO  may  be  a  member  of  another  Private  Organiza¬ 
tion  that  is  philanthropic  and  where  he  performs  in  the  role  of  fundraiser. 

Since  in  the  great  majority  of  circumstances  JWSOL  will  need  to  model,  people  are  associated 
with  organizations,  it  seems  appropriate  to  use  association  classes  to  model  those  roles  determined  by 
the  relationship.  The  content  of  the  association  class  is  sensitive  to  role  and  to  kind  of  organization. 
For  example,  the  links  to  a  Private  Organization  might  include  the  attributes  Mission,  Type_of_Pri- 
vateOrg,  Industry,  Name,  Union_NonUnion,  Person_in_charge_name,  Person_in_charge_title,  Suc¬ 
cessor,  Structure,  Location  of  HQ,  Alternate  HQ,  Field  HQ,  Permanent  Address,  and  Branch 
Address,  for  example.  Humans  relate  to  their  “home”  organization  through  association  classes. 
Otherwise,  it  is  a  direct  association. 
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Figure  34.  Event  class. 


Figure  35.  Agent  subtree  with  Human  and  Organization. 


People  and  organization  are  the  most  interesting  and  important  things  a  Commander  of  a  joint  task 
organization,  such  as  a  Joint  Task  Force,  will  consider.  Agent  is  the  core  unifying  idea  linking  people 
and  organizations.  Both  can  properly  be  said  to  have  goals,  desires,  motivations,  intentions,  and 
plans.  Agents  initiate  actions  to  pursue  goals.  If  you  can  appropriately  think  about  it  as  having  inten¬ 
tions,  it  is  an  agent  (AFSC  Pub.  1,  The  Joint  Staff  Officer’s  Guide  1993,  National  Defense  University, 
Norfolk,  VA). 

Some  Non-Military  Organizations  will  have  subclasses  based  on  mission  or  puipose  of  existence. 
For  example,  a  private  organization  that  has  a  mission  to  provide  services  would  be  classed  as  a  Ser¬ 
vice  Organization  (e.g.,  Kiwanis,  Rotary,  and  Optimist)  (figure  37). 


Figure  37.  Non-Military  Organization  classes. 


The  Military  Organization,  shown  in  figure  38,  is  divided  into  the  U.S.  Military  Organization  class 
and  Other  Military  Organization. 
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Figure  38.  U.S.  Military  Organization. 


The  Army  component  could  perform  a  mission  requiring  a  corps  organization  with  an  assortment 
of  major  combat,  combat  support,  and  combat  service  support  units  of  division,  brigade/regiment, 
and  separate  battalion  size.  Such  a  corps  would  be  categorized  as  “heavy,”  or  “light  mixed,”  and 
could  be  organized  using  a  unique  selection  of  units,  as  shown  in  figures  39  through  41. 
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Figure  39.  Army  component  Corps  class. 


The  Air  Force  component  is  task  organized  to  accomplish  a  specific  mission.  The  organizations 
are  identified  in  figure  42. 

The  U.S.  Navy  component  is  task  organized  to  accomplish  a  specific  mission.  The  Battle  Group 
organization  is  composed  of  physical  ships  (vessels)  that  are  organized  to  accomplish  a  warfighting 
mission.  The  Battle  Group  class  includes  Carrier,  Destroyer,  Frigate,  and  Submarine  (SSN)  assigned, 
as  shown  in  figure  43. 

The  U.S.  Aircraft  Carrier  class,  shown  in  figure  44,  has  five  subclasses:  USS  Nimitz,  USS  Enter¬ 
prise,  USS  John  F.Kennedy,mS  Kitty  Hawk,  and  USS  Forrestal.  The  Human  warfighter  comple¬ 
ment  attribute  and  the  number  of  berths  available  per  platform  are  two  attributes  of  interest  to  the 
theater  CINC. 

The  U.S.  Cruiser  class  has  six  subclasses:  USS  Virginia,  USS  California,  USS  Truxton,  USS 
Ticonderoga,  USS  Belknap,  and  USS  Leahy,  as  shown  in  figure  45. 

The  U.S.  Destroyer  class  has  three  subclasses:  USS  Spruance,  USS  Kidd,  and  USS  Arleigh  Burke 
(figure  46). 
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Figure  40.  Armored  Division. 
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infantry  Division 
(Mechanized) 


Figure  41 .  Infantry  Division  (Mechanized). 


Numbered 
Air  Force 


Control  &  Reporting  Air  Support  Wing  Ops 

Center  Ops  Center  Center 


Control  &  Reporting  Forward  Air  Squadron  Group 

Post  Control  Post 

Note:  Assigned  units  are  task  organized 
to  accomplish  the  missions. 


Figure  42.  Air  Force  component  Numbered  Air  Force  class. 


Figure  43.  Navy  Battle  Group  class. 


Note:  All  provide  25  officer  and  45  enlisted  flag  spaces. 

Carrier  Air  Wing  (CAW)  spaces  are  those  available  for  task 
organizing  the  air  wing. 
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Figure  44.  Navy  Aircraft  Carrier  class. 


Note:  Truxton,  Belknap  and  Leahy  classes 

provide  6  officer  and  12  enlisted  flag  spaces. 


Figure  45.  Navy  Cruiser  class. 
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Figure  46.  Navy  Destroyer  class. 


The  U.S.  Frigate  class  has  two  subclasses:  USS  Oliver  Hazard  Perry  and  USS  Knox  (figure  47). 


Figure  47.  Navy  Frigate  class. 

The  U.S.  Submarine  class  has  four  subclasses:  one  strategic  mission  class,  USS  Ohio  (SSBN),  and 
three  attack  classes,  USS  Sturgeon  (SSN),  USS  Seawolf  (SSN),  and  USS  Los  Angeles  (SSN)  (fig¬ 
ure  48). 


Figure  48.  Navy  Submarine  class. 
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The  Amphibious  Group  organization  is  composed  of  physical  ships  (vessels)  organized  to  accom¬ 
plish  amphibious  assault  from  the  sea  to  land  using  both  surface  and  air  assault  assets.  The  Amphibi¬ 
ous  Group  includes  Amphibious  Assault  Ship  (LHD,  LHA,  LPH),  Amphibious  Command  Ship 
(LCC),  Amphibious  Transport  Dock  Ship  (LPD),  Dock  Landing  Ship  (LSD),  and  Tank  Landing  Ship 
(LST),  as  shown  in  figure  49. 


Figure  49.  Navy  Amphibious  Group  class. 


The  U.S.  Amphibious  Assault  Ship  class  has  three  subclasses:  USS  Wasp,  USS  Tarawa,  and  USS 
Iwo  Jima,  as  shown  in  figure  50. 


Figure  50.  Navy  Amphibious  Assault  Ship  class. 
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The  U.S.  Amphibious  Command  Ship  (LCC)  class  has  one  subclass,  the  USS  Blue  Ridge  (fig¬ 
ure  51). 


Figure  51 .  Navy  Amphibious 
Command  Ship  class. 


The  U.S.  Amphibious  Transport  Dock  class  has  one  subclass,  the  USS  Austin  (figure  52). 


Figure  52.  Navy  Amphibious  Transport 
Dock  class. 
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The  U.S.  Dock  Landing  Ship  (LSD)  class  has  three  subclasses:  USS  Whidbey  Island,  USS  Harper 
Ferry,  and  USS  Anchorage  (figure  53). 


Figure  53.  Navy  Dock  Landing  Ship  class. 


The  U.S.  Tank  Landing  Ship  (LST)  class  has  one  subclass,  the  USS  Newport  (figure  54). 


Figure  54.  Navy  Tank  Landing 
Ship  class. 


The  Replenishment  Group  organization  consists  of  physical  ships  (vessels)  organized  to  replenish 
other  U.S.  naval  vessels  both  at  sea  or  in  port  using  at-sea  replenishment  techniques,  alongside 
replenishment,  and/or  helicopter  replenishment,  depending  on  product  required.  The  Replenishment 
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Group  class  has  five  subclasses:  Ammunition  Ship  (AE),  Combat  Stores  Ship  (AGE),  Oiler  (AO), 
Fast  Combat  Support  Ship  (AFS),  and  Replenishment  Oiler  (AOR),  as  shown  in  figure  55. 


Figure  55.  Navy  Replenishment  Group  class. 


The  U.S.  Marine  Corps  component  is  organized  as  a  Marine  Expeditionary  Force  composed  of 
ground,  aviation,  and  service  support  elements  that  constitute  a  single  weapons  system — the  Marine 
Air-Ground  Task  Force  (figure  56). 


Figure  56.  Marine  Expeditionary  Force  superclass. 
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The  U.S.  Marine  Division  is  task  organized  to  execute  amphibious  assault  operations  and  such 
other  operations  as  may  be  directed,  supported  by  Marine  aviation,  force  service  support  units,  and 
other  supporting  units  (figure  57). 


Figure  57.  Marine  Division  class. 


The  U.S.  Marine  Infantry  Regiment  is  the  major  element  of  close  combat  power  of  the  Marine 
division  (figure  58). 


Figure  58.  Marine  Infantry  Regiment  class. 
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The  U.S.  Marine  Aircraft  Wing  is  task  organized  to  participate  as  the  supporting  air  component  of 
a  Marine  Expeditionary  Force  or  as  an  integral  part  of  navy  aviation  (figure  59). 


Note:  Marine  Aircraft  Wings  are  task  organized. 


Figure  59.  Marine  Aircraft  Wing  class. 


The  U.S.  Marine  Aircraft  Group  (Fixed  Wing)  is  organized  to  conduct  offensive  air  support  and  air 
interdiction  from  land  force  or  carrier  (figure  60). 
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NOTE:  Marine  Aircraft  Groups  are  task  organized. 


Figure  60.  Marine  Aircraft  Group  (Fixed  Wing)  class. 


The  U.S.  Marine  Aircraft  Group  (Rotary  Wing)  provides  assault  support  for  all  Marine  units  (fig¬ 
ure  61). 


NOTE:  Marine  Aircraft  Groups  are  task  organized. 


Figure  61 .  Marine  Aircraft  Group  (Rotary  Wing)  class. 


86 


The  U.S.  Marine  Corps  Force  Service  Support  Group  is  a  composite  grouping  of  functional  com¬ 
ponents  that  provides  support  above  the  organic  capability  of  the  supported  Marine  units  (figure  62). 


Figure  62.  Marine  Force  Service  Support  Group. 


7.5  COMMAND  AND  CONTROL  SUBTREE 

The  Command  and  Control  association  class  is  the  relationship  that  gives  Agent,  Event,  and  Physi¬ 
cal  definition  and  place  in  the  real  world  (figure  63).  The  principal  attributes  of  the  Command  and 
Control  association  class  are  Information  Products,  which  include  objects  such  as  Plan,  Order, 
Report,  Message,  E-Mail,  Memo,  Letter,  Standard  Operating  Procedure  (SOP),  Rules  of  Engagement 
(ROE),  Estimate,  Objective,  Goal,  Course  of  Action,  Mission  Statement,  and  Task  Statement. 
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Figure  63.  Command  and  Control  association  class. 
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8.  PLANS 


This  section  discusses  current,  near-term,  long-term,  and  very  long-term  plans  for  JWSOL. 

8.1  CURRENT  TASKING 

There  are  three  remaining  tasks: 

1 .  Solicit,  analyze,  and  incorporate  comments.  This  document  will  be  circulated,  comments 
solicited,  and  changes  incorporated  into  the  taxonomy  according  to  the  nature  and  quality 
of  the  response  received. 

2.  Expand  class  specifications.  Expand  the  taxonomy  and  its  contents.  The  methods  named  in 
the  current  representation  will  be  further  detailed  by  specifying  their  input  and  output  forms 
and  value  ranges.  State  diagrams  will  be  created  to  represent  changes  of  state  for  key 
classes.  Martin/Odell  event  flows  will  also  be  created  to  represent  typical  envisioned  mis¬ 
sion  and  process  flows. 

3.  Unify,  validate,  and  publish.  All  of  the  material  developed  for  and  received  in  response  to 
the  project  will  be  reviewed.  Recommended  changes  will  be  made  to  the  taxonomy  and  to 
this  document.  A  Joint  Warfare  Taxonomy  document,  companion  to  the  JWSOL  Require¬ 
ments,  will  be  published. 

8.2  NEAR-TERM  OBJECTIVES 

There  are  four  near-term  objectives: 

1 .  Complete  detailed  design;  complete  specification  of  objects.  During  the  second  phase  of  the 
JWSOL  project,  object  specifications  for  the  warfare  objects  defined  in  the  first  phase  will 
be  developed.  These  specifications  will  be  captured  in  an  object  model  developed  and  doc¬ 
umented  with  object-oriented  design  (OOD)  Rumbaugh  software.  The  construction  of  the 
object  specifications  will  be  an  iterative  process  of  prototyping  and  documenting.  Iterations 
will  continue  until  the  entire  set  of  objects,  with  their  related  inheritance  hierarchies  and 
“part-of  ’  hierarchies,  merge  in  a  final  design.  That  design  will  be  documented  iteratively 
and  coded  from  the  specifications.  The  SMEs  will  continue  to  support  evaluation  during  the 
development  of  the  object  specifications. 

2.  Monitor  and  incorporate  evolving  commercial  and  governmental  standards.  Progress  of 
commercial  standards,  such  as  CORBA,  will  be  monitored.  Standards  will  be  reviewed  and 
incorporated  throughout  the  design  and  development  of  JWSOL  objects  to  ensure  compati¬ 
bility  with  commercial  object-oriented  (OO)  products. 

3.  Continue  relationships  with  collaborative  programs.  Coordination  with  collaborative  pro¬ 
grams  will  continue.  Relationships  have  been  established  with  the  JTF-ATD,  OMWG, 

NSS,  JSIMS,  DEEM,  and  JWID-95  programs.  Continued  participation  by  JWSOL  person¬ 
nel  in  working  groups  associated  with  these  programs  will  provide  the  necessary  feedback 
to  ensure  the  success  of  JWSOL. 

4.  Build  prototypes,  deliver  to  programs,  and  perform  beta  test  analysis.  The  third  phase  of 
JWSOL  will  complete  the  prototype  integration  of  COTS  and  GOTS  features  and  concen¬ 
trate  on  the  test  and  evaluation  of  the  library  features.  Operator  and  user  documentation  will 
be  delivered.  The  library  will  be  filled  with  validated  objects  and  the  first  deployments  will 
be  made.  At  the  end  of  this  phase,  the  JWSOL  capability  will  transition  to  life-cycle  main¬ 
tenance. 
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8.3  LONG-TERM  OBJECTIVES 


There  are  six  long-term  objectives: 

1.  Extend  JWSOL  to  other  warfare  and  operations  other  than  war  areas.  A  natural  customer- 
driven  extension  of  JWSOL  is  to  more  levels  of  operations  and  more  kinds  of  operations. 
The  structure  of  the  taxonomy  is  very  friendly  to  such  extension,  which,  in  the  long  run, 
might  result  in  the  merging  of  JWSOL  with  other  taxonomic  efforts. 

2.  Extend  JWSOL  to  multiple  levels  of  resolution.  Multiple  resolution  is  a  difficult  ongoing 
problem  for  M&S.  Possibly  using  the  notion  of  perspectives,  JWSOL  will  be  refined  to 
offer  multiple  levels  of  resolution  on  demand.  This  would  apply  to  multiple  interfaces,  mul¬ 
tiple  attributes,  and  multiple  methods,  satisfying  the  levels  of  resolution  necessary,  as 
defined  by  customer  demand. 

3.  Integrate  knowledge  systems  technology  into  JWSOL.  Several  available  public-domain 
knowledge  system  tools  might  be  integrated  into  JWSOL — CLIPS,  KRSL,  and  KADS  are 
three  examples.  Also,  knowledge  visualization  efforts  are  going  on  in  many  places  in  the 
military — the  Navy  Underwater  Warfare  Center  and  Rome  Laboratory  are  two  reserach 
sites.  Knowledge  systems  tools  and  knowledge  visualization  capabilities  would  be  inte¬ 
grated  to  facilitate  explicit,  user-modifiable  strategy  and  tactics  modeling  as  well  as  deeper 
representation  of  command  and  control  decision  making. 

4.  Build  sample  models  and  applications.  Sample  model  components,  models,  and  applica¬ 
tions  will  be  built  using  JWSOL  classes  and  objects.  These  are  a  valuable  aid  to  program¬ 
mers  new  to  JWSOL  by  providing  a  guide  to  model  construction.  Use  of  sample  programs 
is  standard  in  commercial  software  tool  publishing. 

5.  Interact  to  provide  possible  cross-over  with  JTF-ATD  OMWG  Schema.  The  OMWG  C^ 
Schema,  discussed  in  section  3.4,  has  been  closely  coordinated  with  the  development  of  the 
JWSOL  taxonomy.  That  effort  will  evolve,  based  on  its  customer’s  needs  and  the  rate  at 
which  it  is  fielded.  JWSOL  covers  areas  that  the  OMWG  is  not  intended  to  support,  but  for 
common  ground,  the  potential  exists  for  productive  interaction.  Design  and  implementation 
elements  from  OMWG  will  be  incorporated  where  necessary  to  better  support  JWSOL 
users. 

6.  Integrate  validated  classes  and  objects  into  an  Information  Analysis  Center.  Development, 
implementation,  documentation,  configuration  management,  VV&A,  and  support  activities 
will  be  performed  to  make  the  JWSOL  repository  suitable  for  incoiporation  into  an 
Information  Analysis  Center  (lAC). 

8.4  VERY  LONG-TERM  OBJECTIVES 

Extending  JWSOL  to  the  ultra-fine-grained  acqusition  model  level  is  a  very  long-term  objective. 

ARPA  is  funding  smart  product  model  research,  which  extends  modeling  and  simulation  down  to  the 

CAD/CAM  level,  and  proposed  200-gigabyte  models. 
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APPENDIX  A:  JWSOL  ATTRIBUTES  AND  METHODS 
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Figure  A-1.  Agent,  physical  and  event  classes,  with  a  command  and  control  association. 


Figure  A-2.  Agent  subtree. 
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Figure  A-3a.  Agent  attributes. 


Figure  A-3b.  Agent  methods. 
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Objects  of  this  class  will  specialize 
inherited  methods. 


Figure  A-4a.  Human  attributes. 


Figure  A-4b.  Human  methods. 
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Figure  A-6a.  Role 
association  attributes. 


Figure  A-6b.  Role 
association  methods. 
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Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-6c.  Person/  A-6d.  Person/ 

person  attributes.  person  methods. 
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Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-6e.  Person/  Figure  A-6f.  Person/ 

organization  attributes.  organization  methods. 
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Figure  A-6g.  Organization/ 
organization  attributes. 


Figure  A-6i.  Ally  attributes. 


Figure  A-6k.  Neutral 
attributes. 
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Objects  of  this  class  will  specialize 
inherited  methods. 


Figure  A-6h.  Organization/ 
organization  attributes. 


Figure  A-6j.  Ally  methods. 


Figure  A-61.  Neutral 
methods. 


Figure  A-7a.  Organization  Figure  A-7b.  Organization 

attributes.  methods. 


Figure  A-8a.  Military 
attributes. 


Figure  A-8b.  Military 
methods. 


Note:  Assigned  units  are  task  organized 
to  accomplish  the  missions. 


Figure  A-9.  Air  Force  component  numbered  Air  Force  class. 


Figure  A-10.  Navy  battle  group  class. 
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Figure  A-11 .  Navy  aircraft  carrier  class. 
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Figure  A-12.  Navy  cruiser  class. 


Figure  A-1 3.  Navy  destroyer  class. 


Note:  Oliver  Hazard  Perry  numbers  include 
19  aircrew  spaces. 


Figure  A-1 4.  Navy  frigate  class. 
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Note:  Seawolf,  Los  Angeles  and  Strugeon 
class  SSNs  may  be  assigned  as  a 
Direct  Support  Element  of  a  Battle 
Group. 


Figure  A-15.  Navy  submarine  class. 
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Figure  A-16.  Navy  amphibious  group  class. 


Figure  A-17.  Navy  amphibious  assault  ship  classes. 
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Figure  A-18.  Navy  amphibious  command  ship  class. 


Figure  A-19.  Navy  amphibious  transport  dock  class. 


Figure  A-20.  Navy  dock  tending  ship  class. 
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Figure  A-21 .  Navy  tank  landing  ship  class. 


Figure  A-23.  Marine  expeditionary  force  superclass. 


Figure  A-24.  Marine  combat  force  classes. 
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Figure  A-26.  Reconnaissance 
battalion. 


Figure  A-25.  Infantry  regiment. 
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Figure  A-28.  Artillery  regiment. 


Figure  A-27.  Tank  battalion. 
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Figure  A-29.  Assault  amphibian 
battalion. 
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Figure  A-30.  Headquarters 
battalion. 


Figure  A-33.  Marine  aircraft  wing  classes. 
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Figure  A-35.  Marine  wing 
headquarters  squadron. 


Figure  A-34.  Marine  air 
control  group. 
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Figure  A-37.  Marine  aerial 
refueler  transport  squadron. 


Figure  A-36.  Marine  wing 
support  group. 


A-20 


AGENT 


ORGANIZATION 


MARINE  EXPEDITIONARY  FORCE 


U.S.  MARINE  AIRCRAFT  WING 


MARINE  AIRCRAFT  GROUP  (Fixed  Wing) 

Personnel 

Officers 

(m) 

202 

(n) 

12 

Enlisted 

(m) 

1732 

(n) 

24 

T/0  No.  8800 

AV-8B 

40 

F/A-18A/C 

24 

F/A-18D 

12 

Marine  Aviation  Logistics  Sqdn  (fixed  wing)  (mals  (FW)) 
Marine  Attack  Sqdn  (VMA) 

Marine  Attack  Sqdn  (VMA) 

Marine  Fighter  Attack  Sqdn  (VMFA) 

Marine  Fighter  Attack  Sqdn  (VMFA) 

Marine  All  Weather  Fighter  Attack  Sqdn  (VMFA  (AW)) 


AGENT 


ORGANIZATION 


MARINE  EXPEDITIONARY  FORCE 


U.S.  MARINE  AIRCRAFT  WING 


MARINE  TACTICAL  ELECTRONIC 
WARFARE  SQUADRON 


Personnel 

Officers 


Enlisted 


(m)  120 

(n)  3 

(m)  719 

(n)  6 


110  Ho.  8657Q 


Marine  Tactical  Electronic 
Warfare  Sqdn  Detachment 
(VMAQ  DET) 

VMAQ  DET 
VMAQ  DET 


Figure  A-39.  Marine  tactical 
electronic  warfare  squadron. 


Figure  A-38.  Marine  aircraft  group  (fixed  wing). 
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Figure  A-40.  Marine  aircraft  group 
(rotary  wing). 
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Figure  A-41 .  Marine  force  service  support  group. 
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Figure  A-42.  Headquarters  and 
service  battalion. 
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Figure  A-43.  Maintenance  battalion. 
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Figure  A-44.  Supply  battalion. 


_ ^ 

ORGANIZATION 

3 

MARINE  EXPEDITIONARY  FORCE 

L 

FORCE  SERVICE  SUPPORT  GROUP 

ENGINEER  SUPPORT  BATTALION 

Personnel 

Officers  (m) 

55 

(n) 

3 

Enlisted  (m)  1538 

(n) 

20 

T/0  No.  3400N 

Radio  Set 

68 

Telephone  Switchbd 

4 

Ambulance 

1 

Generator  Set 

253 

Grader,  Road 

5 

Bucket,  2.5  yd 

8 

Crane 

12 

Laundry  Unit 

36 

Concrete  Mixer 

6 

Roller,  Compactor 

4 

Scraper,  Tractor 

6 

Boat,  Bridge 

9 

Bridge  (GOT) 

3 

Bridge,  Floating  Foot 

6 

Bridge,  Med  Girder 

3 

Drum,  Collapsible  500  gal 

56 

Hqtrs  and  Svc.  Co. 

Engineer  Spt.  Co. 

Engineer  Co. 

Bridge  Co. 

Bulk  Fuel  Co. 

Figure  A-45.  Engineer  support 
battalion. 
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Figure  A-46.  Landing 
support  battalion. 
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Figure  A-47.  Motor  transport 
battalion. 
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Figure  A-48.  Medical  battalion. 


Figure  A-49.  Dental  battalion. 
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Figure  A-51 .  Macro  corps. 
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Figure  A-52.  Airborne  infantry. 
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M113A3  365 

M577  185 

M60A1 
M60A2 
M60A3 

AH-1F  8 

AH-1S  8 

AH-1P  6 

AH-1H  18 

AH-64 

CH47 

UH-1 

UH-60A  21 

OH-58C  37 

OH-58 

M992A1  72 

MLRS  9 

203mm 

155mm  72 

105mm  (Ml  19) 

rrv  48 

TOW  ATOM 

107mm  Mort  66 

81mm  Mort  54 

60mm  Mort 

ADA  Gun  27 

Sfinger 

MK19  323 

SAW  504 

ISOcal  m2  756 

AVLB  36 

2.5  Ton  615.119 

HWMMV  1.106 

5  Ton  248.213,34 

W/S250  Shelter 
Truck,  250  gal  208 

M16A2  11.475 

Armed  RecovVeh  94 

Trailer.  5000  gal  64 

CEV  18 


Assigned  Subunits 

DivHHC(O-l) 

MVRBDEHHC(0-3) 

Inf  Battalions  (0-4a)  (light,  abn,  a/asit,  mech) 
Amtor  Battalions  (0-6)  (M60,  M1A1/2) 
DivArtyHHC(O-l) 

FA  Battalions  (0-3)  (155,105) 

FA  Btiys  (0-*)  (Tab,  MLRS,  203mm,  155) 
Avn  Bde  HHC 
ATKHetoBn  (0-1) 

Assauit  Heh  Bn  (0-1) 

Command  Avn  Co  (0-1) 

Division  Supt  Com  HHC  (0-1) 

Med  Bn  (0-1) 

Transport  Bn  (0-1) 

MamtBn  (0-1) 

Engineer  Bn 
CEW1  Bn 
MPCo 
CMLCo 


Level:  Division 

Type:  Air  Assault 

TOE:  67000L200 

ID:  101st  Air  Assault 

Personnel  Strength 
Off 

1,785 

Enl 

13,964 

CBT  Pwr  Equivalent 
Major  Equipment 
M1A1 

0 

M1A2 

M2A2 

M3A1 

M3A2 

M113A3 

M577 

M60A1 

M60A2 

M60A3 

AH-1F 

16 

AH-1S 

AH-1P 

16 

AH-1H 

AH-64 

72 

CH-47D 

48 

UH-1H 

33 

UH-60A 

128 

OH-58C 

91 

OH-58 

1 

M992A1 

MLRS 

203mm 

155mm 

105mm  (M119) 

54 

ITV 

TOW  ATOM 

180 

107  mm  Mort 

81mm  Mort 

36 

60mm  Mort 

54 

ADA  Gun 

27 

Stinger 

180 

MK19 

126 

SAW 

774 

150cal  m2 

AVLB 

2.5  Ton 

406 

HWMMV 

1,283 

5  Ton 

222 

W/S250  Shelter 

268 

Tanker.  250  gal 

72 

M16A2 

(M88)  Armed  Recov  Veh 

Trailer,  5000  gal 
CEV 

Assigned  Subunits 

DivHHC(O-l) 

MVRBDEHHC(0-3) 

Inf  Battalions  (O-a)  (light,  abn,  a/asit,  mech) 
Armor  Battalions  (0^6)  (M60,  M1A1/2) 

Div  Arty  HHC  (0-1) 

FA  Battalions  (0-3)  (155,105) 

FA  Btrys  (0-*)  (Tab,  MLRS,  203mm,  155) 
Avn  Bde  HHC 
ATKHeIoBn(0-2) 

Assault  Helo  Bn  (0-1) 

Command  Avn  Co  (0-1) 

Division  Supt  Com  HHC  (0-1) 

Med  Bn  (0-1) 

Transport  Bn  (0-1) 

Mamt  Bn  (0-1) 

Engineer  Bn 
CEW1  Bn 
MP  Co 
CMLCo 


Figure  A-54.  Air  assault. 


A-32 


Level:  Division 
Type:  Inf  (mechanized) 
TOE:  87000L800 

ID: 


Personnel  Strength 

Off 

1,530 

Enl 

15.524 

CBT  Pwr  Equivalent 

Major  Equipment 

M1A1 

290 

M1A2 

M2A2 

270 

M3A1 

10 

M3A2 

110 

M113A3 

370 

M577 

185 

M60A1 

M60A2 

M60A3 

AH-1F 

8 

AH-1S 

AH-1P 

8 

AH-1H 

6 

AH-64 

18 

CH47D 

UH-1 

UH-60A 

21 

OH^SC 

37 

OH-58 

72 

M992A1 

9 

MLRS 

203mm 

155mm 

72 

105mm  (Ml  19) 

rrv 

60 

TOW  ATOM 

107mm  Mort 

66 

81mm  Mort 

45 

60mm  Mort 

ADA  Gun 

27 

Stinger 

MK19 

348 

SAW 

420 

150calm2 

742 

AVLB 

36 

2.5  Ton 

741 

HWMMV 

1,111 

5  Ton 

460 

W/S250  Shelter 

Tanker,  250  gal 

208 

M16A2 

11,771 

{M88)  Aimed  RecovVeh  94 

Trailer,  5000  gal 

64 

CEV 

18 

Assigned  Subunits 

DivHHC(O-l) 

MVRBDE  HHC(0-3) 

Inf  Battalions  (0-5a)  (light  abn,  a/asit)  mech) 
Armor  Battalions  ((W)  (M60,  M1A1/2) 

Div  Arty  HHC  (0-1) 

FA  Battalions  (0-3)  (155,105) 

(Tab,  MLRS) 

Avn  Bde  HHC 

ATKHeloBn  (0-1) 

Assault  Heio  Bn  (0-1) 

Command  Avn  Co  (0^1) 

Division  Supt  Com  HHC  (0-1) 

Med  Bn  (0-1) 

Transport  Bn  (0-1) 

MaintBn  (0-1) 

Engineer  Bn 
CEWl  Bn 
MP  Co 
CMLCo 


Figure  A-55.  Infantry  (mechanized). 


Level:  Brigade 
Type:  Corps  Avn  Bde 
TOE:  01400L200 

ID: 


Personnel  Strength 

Off  1,053 

Enl  2.867 

CBT  Pwr  Equivalent 

Major  Equipment 

M1A1 

M1A2 

M2A2 

M2A2 

M3A1 

M3A2 

M113A3 

M577 

M60A1 

M60A2 

M60A3 

AH-1F  42 

AH-1E  12 

AH-1P  12 

AH-1H  34 

AH-64  72 

CH47D  64 

UH-1 

UH-60A  108 

OH-58C  108 

OH-58  6 

M992A1 

MLRS 

203mm 

155mm 

105mm  (Ml  19) 

ITV 

TOW  ATOM 
107mm  Mort 
81mm  Mort 
60mm  Mort 
ADA  Gun 
Stinger 
MK19 
SAW 
150cal  m2 
AVLB 

2.5  Ton  333 

HWMMV  375 

5  Ton  577 

W/S250  Shelter  14 

Tnjck,  250gal  75 

M16A2 

Armed  Recovery  Vehicle 
CEV 

Trailer,  5000  gal 

U-21  5 


Assigned  Subunits 

^HHC(O-I) 

MVRBDEHHC{0-3) 

Inf  Battalions  (0-9)  (light,  abn,  a/asit,  mech) 
Armor  Battalions  (0-6)  (M60,  M1A1f2) 

Div  Arty  HHC  (0-1) 

FA  Battalions  (0-3)  (155,105) 

FA  Btrys  (0-*)  (Tab,  MLRS,  203mm,  155) 
Avn  Bde  HHC 
ATKHeloBn(0-2) 

Assault  Halo  Bn  (0-1) 

Command  Avn  Co  (0-1) 

Division  Supt  Com  HHC  (0-1) 

Med  Bn  (0-1) 

Transport  Bn  (0-1) 

MamtBn(0-1) 

Engineer  Bn 
CEW1  Bn 
MP  Co 
CMLCo 


Figure  A-56.  Corps  aviation  brigade. 


Level:  Brigade 

Type:  Corps  Artillery 

TOE:  06403L000 

ID: 

Personnel  Strength 

Off 

199 

Enl  1,922  +  357  = 

2,289 

CBT  Pwr  Equivalent 

Major  Equipment 

M1A1 

M1A2 

M2A2 

M3A1 

M3A2 

M113A3 

M577 

42 

M60A1 

M60A2 

M60A3 

AH-1F 

AH-1S 

AH-1P 

AH-1H 

AH-64 

CH47 

UH-1 

UH-60A 

OH-58C 

OH-58 

M992A1 

72 

MLRS 

27 

203mm 

72 

155mm 

105mm  (Ml  19) 

ITV 

TOWATGM 

107mm  Mort 

81mm  Mort 

60mm  Mort 

ADA  Gun 

Stinger 

MK19 

72 

SAW 

150cal  m2 

105 

AVLB 

2.5  Ton  3,4,4,1.3,69,15.13 

HWMMV  4,11,11,1.5,36,53 

5  Ton 

4.4,36 

W/S250  Shelter 

Tojck,  250  gal 

3,7 

M16A2 

1,809 

Armed  Recov  Veh 

13 

Trailer,  5000  gal 

CEV 

Assigned  Subunits 

DivHHC  (0*1) 

MVRBDE  HHC  (0-3) 

Inf  Battalions  (0-9)  (fight,  abn,  a/astt,  mech) 
Armor  Battalions  (ds)  (M60,  M1A1/2) 

DIv  Arty  HHC  (0-1) 

FA  Battalions  (0-3)  (155,105,203) 
3Busw/rOE:06445J420 

1  MLRS  Bn  TOE: 

FA  Btrys  (0-*)  (Tab  TOE:  06413L000, 

MLRS,  203mm,  155) 

AvnBde  HHC 

Ar/(He/ofi/7fO-2j 

Assault  Helo  Bn  (0-1) 

Command  Avn  Co  (0-1) 

Division  Supt  Com  HHC  (0-1) 

Med  Bn  (0-1) 

Transport  Bn  (0-1) 

Mamt  Bn  (0-1) 

Engineer  Bn 

CEW1  Bn 

MPCo 

CMLCo 

Figure  A-57.  Corps  artillery. 


A-35 


Level:  Brigade 
Type:  FA  Brigade 
TOE:  06402L200 
ID: 


Personnel  Strength 

Off 

Enl 

CBT  Pwr  Equivalent 

Major  Equipment 

M1A1 

M1A2 

M2A2 

M3A1 

M3A2 

M113A3 

M577  27 

M60A1 

M60A2 

M60A3 

AH-.1F 

AH-1S 

AH-1P 

AH-1H 

AH*64 

CH-47 

UH-I 

UH-60A 

OH-58C 

OH-58 

Mg92A1 

MLRS 

203mm  54 

155mm 

105mm  (Ml  19) 

ITV 

TOW  ATOM 
107mm  Mort 
81mm  Mort 
60mm  Mort 
ADA  Gun 
Stinger 
MK19 
SAW 

150calm2  66 

AVLB 

2.5  Ton  3,1,60,21 

HWMMV  9.2.45,27,87,8 
5  Ton  10,1,4 

W/S250  Shelter  9.6 
Tanker.  250  gal 
M16A2  135,1800 

M88  Armed  Recov  Veh  9 
Trailer,  5000  gal 
CEV 


Assigned  Subunits 

DivHHC  (0-1) 

MVRBDE  HHC(0-3) 

Inf  Battalions  (O^Q)  (light,  abn,  a/asJt,  mech) 
Armor  Battalions  (0^)  (M60,  M1A1/2) 
DivArtyHHC(0-1) 

FA  Battalions  (0-3)  (155,105,203) 

FA  Btrys  (0^*)  (Tab,  MLRS,  203mm,  155) 
AvnBdeHHC 
ATKHeloBn(0-2) 

Assault  Heh  Bn  (0-1) 

Command  Avn  Co  (0-1) 

Division  Supt  Com  HHC  (0-1) 

Med  Bn  (0-1) 

Transport  Bn  (0-1) 

MamtBn  (0-1) 

Engineer  Bn 
CEW1  Bn 
MPCo 
CMLCo 
3x8*  Bus  TOE: 

TabBtfyTOE: 


Figure  A-58.  FA  brigade. 


Level:  Brigade 

Type:  Engineer  Corps  Bde 

TOE;  05330L000 

ID: 


Personnel  Strength 

Off  92 

Enl  1.262 

CBTPwr  Equivalent 

Major  Equipment 

M1A1 

M1A2 

M2A2 

M3A1 

M3A2 

M113A3  87 

M577  9 

M60A1 

M60A2 

M60A3 

AH-1F 

AH-1S 

AH-1P 

AH-1H 

AH-64 

CH47 

UH-1 

UH-60A 

OH-58C 

OH-58 

M992A1 

MLRS 

203mm 

155mm 

105mm  (Ml  19) 

ITV 

TOW  ATOM 
107mm  Mort 
81mm  Mort 
60mm  Mort 
ADA  Gun 
Stinger 
MK19 
SAW 
150cal  m2 

AVLB  36 

2.5  Ton  35 

HWMMV  115 

5  Ton  9 

W/S250  Shelter 
Tanker,  250  gal  12 

M16A2  98 

M88  Armed  Recov  Veh  6 
Trailer,  5000  gal 
CEV  18 


Assigned  Subunits 

DivHHC(O-l) 

MVRBDE  HHC(0-3) 

/nf  Battalions  (0-aJ  (light,  abn,  a/aslt,  mech) 
Armor  Battalions  (0-6)  (M60,  M1A1/2) 
DivArtyHHC  (0-1) 

FA  Baffa/zons  (0-3)  (155,105) 

FA  Btrys  (0-*)  (Tab,  MLRS,  203mm,  155) 
AvnBdeHHC 
ATKHeloBn(O-l) 

Assault  Heio  Bn  (0-1) 

Command  Avn  Co  (0-1) 

Division  Supt  Com  HHC  (0-1) 

Med  Bn  (0-1) 

Transport  Bn  (0-1) 

Mamt  Bn  (0-1) 

Engineer  Bn 
CEW1  Bn 
MPCo 
CMLCo 


Figure  A-59.  Engineer  corps  brigade. 


Level:  Brigade 
Type:  CEWl 
TOE:  34400L200 
ID: 


Personnel  Strength 

Off 

Enl 

CBT  Pwr  Equivalent 

Major  Equipment 

M1A1 

M1A2 

M2A2 

M3A1 

M3A2 

M113A3 

M577 

M60A1 

M60A2 

M60A3 

AH-1F 

AH-1S 

AH-1P 

AH-1H 

AH-64 

CH-47 

UH-1 

UH-60A 

OH-58C 

OH-58 

M992A1 

MLRS 


316 

1,457 


14 


203mm 

155mm 

105mm  (M119) 

rrv 

TOW  ATOM 
107mm  Mort 
81mm  Mori 
60mm  Mort 
ADA  Gun 
Stinger 
MK19 
SAW 
ISOcal  m2 
AVLB 

2.5  Ton  73.10 

HWMMV  64.70,54,38 
5  Ton  15.18.9 

W/S250  Shelter 
Tanker,  250  gal  4 

M16A2  1.462 

M88  Armed  Recov  Veh  4 
Trailer,  5000  gal 
CEV 

OV-10  10 

U-21  6 

C-12  6 


Assigned  Subunits 


DivHHC(0-1) 

MVRBDE  HHC{0-3) 

Inf  Battalions  (0-a)  fight,  abn,  a/asit,  mech) 
Armor  Battalions  (0-6)  (M60,  M1A1/2) 

Div  Arty  HHC  (0-1) 

FABattalions  (0-3)  (155,105) 

FABtrys  (0-*)  (Tab.  MLRS,  203mm.155) 
AvnBdeHHC 

ATKHeloBn(O-l) 

Assault  Helo  Bn  (0-1) 
CommandAvnCo(O-l) 

Division  Supt  Com  HHC  (0-1) 

Med  Bn  (0-1) 

Transport  Bn  (0-1) 

MaintBn  (0-1) 

Engineer  Bn 
CEWl  Bn 
MP  Co 
CMLCo 

Corps  CEWl  Brigade: 

HHD:  34202L00O 
Ops  Bn;  34225L000 
MIBn  (TE):  34225L000 
AEB;  34415L200 


Figure A-60.  CEWl. 


A-38 


Level:  Battalion 

Type:  Airborne  Inf 

TOE:  07035L0O0 

ID:  1Bn/1Bde/82ABN 


Personnel  Strength 

Off  42 

En!  637 

CBTPwr  Equivalent 
Major  Equipment 

Tubular  Launched  Guided  MsLL45740  20 

Night  Vision  Goggle:  AN/PVS'7B_N05482  31 6 

Terminal  Radio-Telephone  Mobile:  T55957  2 

Night  Sight  Equipment  (TOW2):  N04982  20 

Trk,  Utility:  Cargo/Troop  Carrier  T61 494  36 

Trk,  Utility:  Tow  Carrier  T05096  20 

Radio  Set  AN/PRC-1 19:  R55268  55 

Trk,  Cargo:  2-1/2  Ton  6x6  W/E:  X40009  10 

Night  Vision  Sight-Tracker:  N23721  18 

Radio  Set:  AN/VRC-88:  R44727  26 

Night  Vision  Sight  Individual:  N04732  106 

Radio  Set  ANAmC-92:  R45339  1 1 

Viewer  Infrared:  AN/PAS-7 :  Y03 104  15 

Speech  Security  Equipment  TSE:  S01373  117 

Radio  Set  ANA/RC-91 :  R45271  1 1 

Rifle  5.56mm  M16A2:  /R95035  464 

Machine  Gun  Grenade  40mm:  M92362  14 

Mask  Chemical  Biological:  M40:  M12418  701 

Trk,  Ambulance:  2  Utter  Armed:  T38707  4 

Tracker,  Infrared  Guided  Msl:  W807 15  18 

Mortar,  60mm:  On  Mount  M67939  6 

Machine  Gun  5.56mm:  M09009  90 

Training  Set  Guided  Msl  Sys:  X04584  5 

Radio  Set  AN/PRC-126:  R55336  50 

Shelter  System  Collective  Protection:  T00474  2 
Radial  Set  AN/PDR-75:  R30925  12 

Mortar  81mm  Sys:  M021 14  4 

Monitor  Chemical  Agent:  C05701  12 

Rifle,  5.56mm  M4:  R97234  145 

Platoon  Early  Warning  System:  P06148  10 

Laser  Infrar^  Obsenration  Set  L40063  1 7 

Just  Kit  MK-2326/VRC:  J47457  24 

Radio  Set  AN/VRC-90:  R45203  7 

Camouflage  Screen  System:  Wood:  C89145  157 
Computer  Set  Ballistics:  Mortar  C60294  8 

Motorcycle:  2  Wheel:  244650  15 

Subunits: 

HHC  1 

Rifle  Company  3 

Weapons  Company  1 


Figure  A-61.  Airborne  infantry. 


A-39 


Level:  Company 

Type:  Airborne  inf 

TOE: 

ID:  A  Co.,  1st  Bn,  1st  Bde,  82nd  Airborne 

Personnel  Strength 

Off 

6 

Enl 

164 

CBT  Pwr  Equivalent 

Major  Equipment 

Night  Vision  Goggle:  AN/PVS-7B:  N05482 

80 

Trk,  Utility:  Cargo/Troop  Carrier:  T61494 

6 

Radio  Set:  AN/PRC-119:  R55268 

12 

Trk,  Cargo:  2-1/2  Ton  6x6  W/E:  X40009 

1 

Radio  Set  AN/VRC-88:  R44727 

5 

Night  Vision  Sight  Individual:  N04732 

90 

Radio  Set  AN/VRC-92;  R45339 

2 

Viewer  Infrared:  AN/PAS-7:  Y03104 

2 

Speech  Security  Equipment  TSE:  S01373 

22 

Radio  Set  AN/VRC-91:R45271 

2 

Rifle  5.56mm:  M16A2:R95035 

103 

Machine  Gun  Grenade  40mm:  M92362 

4 

Mash  Chemical  Biological:  M40:  M12418 

175 

Mortar,  60mm:  On  Mount:  M67939 

2 

Machine  Gun:  5.56mm:  M09009 

26 

Radio  Set  AN/PRC-126:  R55336 

13 

Radio  Set  AN/PPR-75:  R30925 

2 

Monitor,  Chemical  Agent:  C05701 

2 

Rifle,  5.56mm:  M4:  R97234 

32 

Platoon  Early  Warning  System:  P06148 

3 

Laser  Infrar^  Observation  Set:  L40063 

2 

Radio  Set:  AN/VRC-90:  R45203 

2 

Camouflage  Screen  System:  Wood:  C89145 

24 

Computer  Set  Ballistics:  Mortar  C60294 

2 

Subunits 

Co.  Headquarters  Section 

1 

Wpns  Pit 

1 

Rifle  Platoons 

3 

Figure  A-62.  Airborne  infantry. 


Figure  A-63a.  Non-military  Figure  A-63b.  Non-military 

attributes.  methods. 


A-40 


A-41 


Religious  Organization 

Religious  Organization 

Mission 

Type_ofReligiousOrg 

Name 

Person_ln_charge_name 

PersonJn_charge_tit!e 

Successor 

Structure 
-Location  of  HQ 
— Alternate  HQ 
-Branch  Address 

Assist  Relief  Services 

Assist  Communications  with  Populace 

Provide  Counseling  Services 

Provide  Funeral  Services 

Figure  A-64a.  Non-military 
organization  attributes. 

Figure  A-64b.  Non-military 
organization  methods. 

Political  Organization 

Political  Organization 

Mission 

Type_ofPoliticaIOrg 

Name 

Person  Jn_charge_name 
Person_in_chargeJitle 

Successor 

Structure 
-Location  of  HQ 
— Alternate  HQ 
—Field  HQ 
— Permanent  Address 
-Branch  Address 

Request  Status 

Mobilize  Groups 

Figure  A-64c.  Political  organization  Figure  A-64d.  Political  organiza- 

attributes.  tion  methods. 


Public  Organization 

Public  Organization 

Mission 

Define  Mission 

Type_oLPublicOrg 

Report  Assets 

Industry 

Name 

Union_NonUnion 

Person_in_charge_name 

PersonJn_charge_title 

Successpr 

Structure 
-Location  of  HQ 
— Alternate  HQ 
—Field  HQ 
— Permanent  Address 
— Branch  Address 

Support  Relief  Operations 

Figure  A-64e.  Public  organization  Figure  A-64f.  Public  organization 

attributes.  methods. 


A-42 


Private  Organization 

Private  Organization 

Mission 

Report  Inventory 

Type_ofPrivateOrg 

Provide  Services 

Industry 

Name 

Union_NonUnion 

PersonJn_charge_name 

Person_in_charge_tit!e 

Successor 

Structure 
-Location  of  HQ 
—Alternate  HQ 
—Field  HQ 
— Permanent  Address 
—Branch  Address 

Provide  Material 

Figure  A-64g.  Private  Figure  A-64h.  Private 

organization  attributes.  organization  methods. 


Government  Organization 

Government  Organization 

Agency/Branch 

Provide  Authorization 

Name 

Implement  Policy 

Address_mail 

Address_msg_PLAD 

Provide  Direction 

Person  Jn_charge_name 
PersonJn_charge_title 

Charter  (function) 

Successor 

Structure 
-Location  of  HQ 
-Alternate  HQ 
—Field  HQ 

—Permanent  Address 
—Branch  Address 

Provide  Support 

Figure  A-64i.  Government  Figure  A-64j.  Government 

organization  attributes.  organization  methods. 


Crew 

Crew 

Number  of  Members 

Assess  Readiness 

Readiness 

Determine  Casualties 

Training 

Operate  Equipment 

Skill  Distribution 

Request  Resupply 

Consume  Resources 

Figure  A-65a.  Crew  attributes.  Figure  A-65b.  Crew  methods. 
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Figure  A-66.  Physical  subtree. 


Figure  A-67a.  Physical  attribute.  Figure  A-67b.  Physical  method. 
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Aircraft 

Aircraft 

Type 

Change  Status 

Model 

Change  Speed 

Series 

Change  Course 

Crew 

Report  Status 

Location 

Takeoff 

Unrefueled  Ferry  Range 

Fly 

Range  with  In-Flight  Refueling 

Land 

Max  Speed-Sea  Level 

Refuel 

Cruise  Speed 

Be  Maintained 

Fuel  Capacity 

Rendevous 

Status 

Threat  Signature 

Min  T-O  Distance 

Service  Ceiling 

Min  Landing  Distance 

Length 

Height 

Wingspan 

Wheelbase 

Max  Gross  T-O  Weight 

Max  Climb  Rate  at  Sea  Level 

Number  of  Engines 

Identification 

Country  of  Origin 

Country  of  Operation 

Max  Hover  Height 

Max  Hover  Weight 

Empty  Weight 

Fly  in  Formation 

Scheduled  Maintenance 

Primary  Configuration  Code 

IFF  Code 

Figure  A-69a.  Aircraft  attributes. 

Figure  A-69b.  Aircraft  methods. 

Fighting 

Fighting 

Max  Climb  Rate 

Calculate  Maximum  Speed/Altitude 

“g”  Limits  ± 

Calculate  Maximum  Angle  of  Attack  at  Speed 

Aspect  Ratio 

Max  Speed  at  Altitude 

Max  Range  with  External  Tanks 

Combat  Ceiling 

Evade/Avoid 

External  Tank  Restrictions 

Combat  Air  Patrol  Endurance  (at  distance) 
Aiming  System 

Electronic  Countermeasures  Suite 
Cryptographic  Communications  Suite 

Radar  Warning  Receiver 

Head  Up  Display— yes/no 

Figure  A-70a.  Fighting  attributes.  Figure  A-70b.  Fighting  methods. 
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Attack 

Attack 

Max  External  Stores 

Strafe 

Hi-Lo-Hi  Range 

Drop  Bomb 

Bombing  System 

Helifire,  yes/no 

Maverick,  yes/no 

Sidewinder,  yes/no 

Mk  Series  Bombs,  yes/no 

Mk  Series  LGB,  yes/no 

Bullpup,  yes/no 

HARM,  yes/no 

Rockeye,  yes/no 

CBU59,  yes/no 

GATOR  Mines,  yes/no 

Laser  Spot  Tracker,  yes/no 

Launch  Rockets 

Figure  A-71  a.  Attack  attributes.  Figure  A-71b.  Attack  methods. 


Fighter 

Fighter 

Max  Combat  Radius 

Strafe 

Max  Radar  Range 

Shoot  Missiles 

Radar  Discrimination  at  Max  Rng 

Pulse  Doppler  Radar-yes/no 

IFF  Interrogator-yes/no 

Internal  Gun-yes/no 

Phoenix-yes/no 

Sparrow-yes/no 

Sidewinder-yes/no 

AMRAAM-yes/no 

Engage 

Figure  A-72a.  Fighter  attributes.  Figure  A-72b.  Fighter  methods. 


Bomber 

Bomber 

Air  Launch  Cruise  MIssile-yes/no 

Bomb 

Covert  Strike  Radar-yes/no 

SRAM  II  Capable-yes/no 

Cleared  for  Nuclear  Delivery-yes/no 

Figure  A-73a.  Bomber  attributes.  Figure  A-73b.  Bomber  methods. 


Electronic  Warfare  (EW) 

Electronic  Warfare  (EW) 

Jamming  Transistors 

Detect 

Auto  Detection-yes/no 

Jam 

Auto  ID-yes/no 

Report 

Auto  Direction  Finding-yes/no 

Identify 

Coherent  Countermeasures  Capability-yes/no 

Locate 

Universal  Exciter  Upgrade 

Track 

Figure  A-74a.  Electronic  warfare  Figure  A-74b.  Electronic  warfare 

attributes.  methods. 
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Command  and  Control  (C^) 

Command  and  Control  (C^) 

Airborne  Very  Low  Frequency  Capable-yes/no 

Control 

SATCOM  UNF  Capable~-yes/no 

Assign 

Radar  Capable-yes/no 

Communicate 

Pulse  Doppler  Radar-yes/no 

Sends  Messages 

Beyond  the  Horizon  Radar  Capable-yes/no 
Maritime  Detection  Capable~yes/no 

HF  Capable-yes/no 

VHF  Capable-yes/no 

UHF  Capable-yes/no 

Report 

Figure  A-75a.  attributes. 


Figure  A-75b.  methods. 


Reconnaissance 

Reconnaissance 

Pod  Required-yes/no 

Take  Pictures 

Camera  Specified 

Analyze  Picture 

SLAR  Capable 

Transmit 

Figure  A-76a.  Reconnaissance  Figure  A-76b.  Reconnaissance 

attributes.  methods. 


ASW 

ASW 

Sonar  Tape  Recorder-yes/no 

Drop  Sonar  Buoy 

Magnetic  Anomaly  Detector-yes/no 

Drop  Bomb 

Time-Code  Generator-yes/no 

Drop  Torpedo 

Sonar  Tape  Recorder-yes/no 

Detect 

Set  Anomaly  Detector-yes/no 

Track 

Magnetic  Compensator-yes/no 

360°  Radar-yes/no 

MK46  Torpedo-yes/no 

MK50  Torpedo-yes/no 

MK54  Depth  Bomb-yes/no 

MK82  Bomb-yes/no 

MK83  Bomb-yes/no 

MK60  Torpedo-yes/no 

Identify 

Figure  A-77a.  ASW  attributes. 

Figure  A-77b.  ASW  methods. 

Transport/Payload 

Transport/Payload 

Door  Dimension 

Load 

Number  Passengers 

Unload 

Cargo  Space-Length 

Transport 

Cargo  Space-Width 

Cargo  Space-Height 

Payload  at  Max  Fuel 

FAA  T-0  Distance 

FAA  Landing  Distance 

External  Max.  Wt. 

Delivery  and  Container  Release  System 
Aircraft  Call  Sign 

Cargo  Hook 

Mission  Radius 

Inflight  Refueling  Capability 

Air  Drop 

Figure  A-78a.  Transport/payload  Figure  A-78b.  Transport/payload 

attributes.  methods. 
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Supply/Equipment 


Countermeasures 
Ski  Equipped 
Pontoons 
Pallet  Capacity 
Troop  Capacity 
Vehicle  Capacity 

Ground  Proximity  Extraction  Capability 
Low  Altitude  Parachute  Extraction  System 


Figure  A-79a.  Supply/equipment  Figure  A-79b.  Supply/equipment 

attributes.  methods. 


Figure  A-80a.  Aeromedical  evacu-  Figure  A-80b.  Aeromedical  evacu¬ 
ation  attributes.  ation  methods. 


Figure  A-81a.  Personnel  attributes.  Figure  A-81b.  Personnel  methods. 


Special  Ops 

Nose  Radome  with  Retrieval  Yoke 
Terrain  Following  Radar 
Secure  Voice 
Inertial  Navigation  System 
Refueling  Probe 
Container  Release  System 
IR  Detection  System 
1 05  mm  Howitzer 
40  mm  Cannon 
20  mm  Cannon 


Figure  A-82a.  Special  ops  Figure  A-82b.  Special  ops 

attributes.  methods. 
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Combat  Rescue 

Combat  Rescue 

Rescue  Hoist 

Lift 

Retrieval  Yoke 

Locate 

Sea  Search  Radar 

Rescue  Kit  Drop  Platform 

Camera  with  Data  Annotation 

IR  Scanner 

Aerial  Recovery  Package 

Extract 

Figure  A-83a.  Combat  rescue 

Figure  A-83b.  Combat  rescue 

attributes. 

methods. 

Air  Refueling  Ops 

Air  Refueling  Ops 

Max  Fuel  Capacity  with  Auxiliary  Tank 

Provide  Fuel 

Transfer  Flow  Rate 

Helicopter  Capable 

Pylon  Fuel  Tank 

Extended  Range 

Max  Fuel  to  Offload  at  Mission  Radius 

Rendezvous 

Figure  A-84a.  Air  refueling  ops  Figure  A-84b.  Air  refueling  ops 

attributes.  methods. 
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Vessel 

Vessel 

Status 

Change  Status 

Beam 

Change  Course 

Fuel  Capacity 

Dock 

Threat  Signature 

Load 

Type 

Unload 

Class 

Be  Maintained 

Displacement 

Change  Speed 

Dimensions 

Take  on  Fuel 

Draft 

Consume  Supplies 

Hull  Dynamics 

Rendezvous 

Main  Propulsion  Type 

Number  of  Main  Propulsion  Plants 

Aux  Propulsion  Type 

Number  of  Aux  Propulsion  Plants 

Screw  Type 

Number  of  Screws 

Speed 

Acceleration 

Deceleration 

Move  in  Convoy 

Range 

Endurance 

Pitch 

Roll 

Yaw 

Turning  Radius 

Turn  Rate 

Reserve  Buoyancy 

Fuel  Type 

Fuel  Consumption  Rate 

Stores  Capacity 

Stores  Consumption  Rate 

Water  Storage  Capacity 

Water  Making  Capacity  (rate) 

Complement 

Communications 

Sensors 

Navigation/GPS 

Fire  Control  Systems 

Weapons 

Countermeasures 

Radiated  Noise 

Radar  Cross  Section 

Damage  Vulnerabilities 

Figure  A-86a.  Vessel  attributes.  Figure  A-86b.  Vessel  methods. 


Transport 

Transport 

Cargo  Capacity 

Load 

Military  Lift  Capacity 

Unload 

Transport 

Figure  A-87a.  Transport  attributes. 


Figure  A-87b.  Transport  methods. 


Military  Sealift  Command  (MSC)/ 
Maritime  Pre-Positioned  Ships  (MPS) 

Military  Sealift  Command  (MSC)/ 
Maritime  Pre-Positioned  Ships  (MPS) 

Aircraft  Capability 

Container  Capacity 

Crane  Capacity 

Medical  Facilities 

Cargo  Loading  Method 

Store  Equipment 

Maintain  Equipment 

Provide  Equipment 

Figure  A-88a.  Military  Sealift 

Command  (MSC)/Maritime  Pre- 
Positioned  Ships  (MPS)  attributes. 

Figure  A-88b.  Military  Sealift 
Command  (MSC)/Maritime  Pre- 
Positioned  Ships  (MPS)  methods. 

Ferry/Barge 

Ferry/Barge 

Lifting  Capacity 

Load  Method 

Objects  of  this  class  will  specialize 
inherited  methods 

Figure  A-89a.  Ferry/barge 
attributes. 

Figure  A-89b.  Ferry/barge 
methods. 

Amphibious  Assault 

Amphibious  Assault 

Flight  Deck 

Aircraft  Embarked 

Command/Control 

Launch  Aircraft 

Recover  Aircraft 

Control  Aircraft 

Launch  Small  Boats 

Recover  Small  Boats 

Figure  A-90a.  Amphibious 
assault  attributes. 

Figure  A-90b.  Amphibious 
assault  methods. 

Air  Assault 

Air  Assault 

Fixed  Wing  Aircraft  Embarked 

Aircraft  Launch  Envelope 

Launch  Aircraft 

Recover  Aircraft 

Figure  A-91  a.  Air  assault 
attributes. 

Figure  A-91b.  Air  assault  methods. 

Sea  Assault 

Sea  Assault 

Amphibious  Craft  Capacity 

Launch  Envelopes 

Launch  Amphibious  Craft 

Recover  Amphibious  Craft 

Figure  A-92a.  Sea  assault 
attributes. 

Figure  A-92b.  Sea  assault 
methods. 

Civil  Reserve 

Civil  Reserve  ! 

Lifting  Capacity 

Load  Method 

Objects  of  this  class  will  specialize 
inherited  methods 

Figure  A-93a.  Civil  reserve 
attributes. 

Figure  A-93b.  Civil  reserve 
methods. 
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Tender 

Perform  Maintenance 

Rendezvous 

Perform  Repair 

Figure  A-94b.  Tender  methods. 

Mine  Warfare 

Deploy  Mines 

Detect  Mines 

Clear  Minefields 

Figure  A-95b.  Mine  warfare 
methods. 

Replenishment 

Replenish 

Rendezvous 

Figure  A-96b.  Replenishment 
methods. 

Floating  Drydock 

Perform  Maintenance 

Perform  Repairs 

Figure  A-97b.  Floating  drydock 
methods. 

Salvage 

Locate 

Recover 

Tow 

Figure  A-98b.  Salvage  methods. 

Command 

Objects  of  this  class  will  specialize 
inherited  methods 

Tender 

Repair  Facilities/Equipment 

Diving  Support  Capability 

Crane  Capacity 

Medical  Facilities 

Recompression  Chamber 

Deep  Submergece  Capability 

Figure  A-94a.  Tender  attributes. 

Mine  Warfare 

Aircraft  Embarked 

Cargo  Capacity 

Figure  A-95a.  Mine  warfare 
attributes. 

Replenishment 

Cargo  Type 

Replenishment  Stations 

Cargo  Capacity 

Aircraft  Embarked 

Figure  A-96a.  Replenishment 
attributes. 

Floating  Drydock 

Load  Capacity 

Lifting  Capacity 

Construction  Materia! 

Figure  A-97a.  Floating  drydock 
attributes. 

Salvage 

Diving  Support  Capability 

Recompression 

Lifting  Capacity 

Figure  A-98a.  Salvage  attributes. 

Command 

Command/Control 

Figure  A-99a.  Command  attributes.  Figure  A-99b.  Command  methods. 


A-54 


Fleet  Tug 

Tow  Capacity 

Pump  Capacity 

Figure  A-1 00a.  Fleet  tug  attributes. 

Fighting 

Combat  Data  Systems 

Command/Control 

Figure  A-1 01  a.  Fighting  attributes. 

Aircraft  Carrier 

Type 

Right  Deck  Size 

Number  of  Fixed  Wing  Aircraft 

Number  of  Rotary  Wing  Aircraft 

Refueling  Capabilities 

Aircraft  Launch  Envelope 

Medical  Facilities 

Figure  A-102a.  Aircraft  carrier 
attributes. 

Patrol  Boats  PHM 

Type 

Special  Forces  Complement 

Diving  Support  Facilties 

Figure  A-1 03a.  Patrol  boats 
PHM  attributes. 

Cruiser 

Type 

Phased  Array 

ASW  Aircraft  Embarked 

Figure  A-1 04a.  Cruiser  attributes. 

Frigate 

Type 

Sonar-A 

Sonar-P 

ASW  Aircraft  Embarked 

Fleet  Tug 

Push 

Tow 

Pump 

Figure  A-1 00b.  Fleet  tug  methods. 

Fighting 

Intercepts 

Locate 

Pursue 

Attack 

Defend 

Engage 

Figure  A-1 01b.  Fighting  methods. 

Aircraft  Carrier 

Launch  Aircraft 

Remove  Aircraft 

Figure  A-1 02b.  Aircraft  carrier 
methods. 

Patrol  Boats  PHM 

Detect 

Intercept 

Figure  A-1 03b.  Patrol  boats 
PHM  methods. 

Cruiser 

Launch  Missiles 

Figure  A-1 04b.  Cruiser  Methods. 

Frigate 

Launch  Missiles 

Figure  A-1 05a.  Frigate  attributes.  Figure  A-1 05b.  Frigate  methods. 
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Destroyer 

Destroyer 

Type 

Phased  Array 

ASW  Aircraft  Embarked 

Provide  Nava!  Gunfire  Support 

Figure  A-1 06a.  Destroyer  attrib- 

Figure  A-1 06b.  Destroyer  meth- 

utes. 

ods. 

Submarine 

Submarine 

Type 

Submerge 

Ballistic  Missiles. 

Fire  Torpedo 

Crush  Depth 

Fire  Missile 

Design  Depth 

Test  Depth 

Periscope  Depth 

Speed  (dived) 

Speed  (surfaced) 

Endurance  (submerged) 

Surface 

Figure  A-1 07a.  Submarine  attrib-  Figure  A-1 07b.  Submarine  meth- 

utes.  ods. 


CG  Cutter 

CG  Cutter 

Type 

Search 

NBC 

Locate 

Aircraft  Embarked 

Rescue 

Supply 

Figure  A-1 08a.  CG  Cutter  attrib-  Figure  A-1 08b.  CG  Cutter  meth- 

utes.  ods. 
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■57 


Land  Vehicle 


Land  Vehicle 


Platfonm_LandVehicle 

Identity 

Country^Origin 

Country_Operation 

Make 

Model 

SerialNumber_Vehicle 

Color 

LIN# 

CamouflageSchema 

BumperlDN  umber 

SeriaiNumber_Convoy 

Status 

Location 

Destination 

Range_Average 

Range^Extended 

TopSpeed 

PlanningSpeed 

ActualSpeed 

PlanningDirection 

ActualDirection 

Type_Armor 

Locat[on_Amnor 

Weapon_Type 

MobilitySystem_Typ0 

Ax!e_Number 

AxIe_Location 

Wheels_Number 

Wheels_Location 

BogieWheels_N  umber 

BogieWheels_Location 

TraiiingWheeis_Number 

TraillngWheels_Location 

GuideWheels_Number 

GuideWheels_Location 

DriveWheels_NumbBr 

DriveWheels_Location 

Chassis_Afticulation 

Crew_Type 

Crew^Number 

FueLType 

FueLCapacity 

FueLConsumptionRate 

Body_Length 

Body.Width 

Body_Height 

GroundClearance_Minimum 

GroundClearance_Maximum 

Tire_Width 

Tire_Type 

Tire_Size 

Track_LinkSize 


Track_Type 

Track_LinkWidth 

Track_LengthOnGround 

Weight_Unloaded 

Weight_Combat 

GroundPressure 

Vehicle_Cube 

Max_RoadSpeed 

Max_CrossCountrySpeed 

Max_FordingDepth_Llnprepared 

Max_FordingDepth_P  repared 

Type^FordingEquipment 

Maxjii^erticalObstacleHeight 

Max_Trench  Width 

Location_CrewCompartment 

Engine_Location 

Engine_Type 

Engine_NumberCylinders 

Engine^Horsepower 

Ratio_HorsepowerToWeight 

Transmission_Type 

Steering_Type 

Driver_Location 

Suspension_Type 

Navtgation_Type 

VisionSystem_Type 

TumingRadius 

Acceleration 

Amphibious 

AmphtbiousDrive_Type 

ElectricalSystem_Voltage 

Communications_System 

Toolkit 

Spare_MobilityGear 

MaxPercent_Slope 

MaxPercent_Gradient 

Associated_Traiier 

Rem  oteG  uIdanceSys 

Photo 

ManuaLOperating 

ManuaLMaintenance 

ManuaLTacticalEquipment 

NBCSys 

Type_VisMod 

Type_Visip 

TypeJFF 

Type_Camouf!ageSchema 

CenterOfGravity_Empty 

CenterOfGravity_Loaded 

TowPoint_Type 

TowPoint_Capaclty 

TowPoint_Location 


Load 

Move 

Unload 

Consume 

Determine  Status 

Rendezvous 

Move  in  Convoy 


Figure  A-IIOa.  Land  vehicle  attributes.  Figure  A-IIOb.  Land  vehicle  methods. 


Figure  A-111.  Fighting. 
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Land  Vehicle-Fighting 

Land  Vehicle-Fighting 

Type_Configuration 

MissionArea 

Type_WpnsSystem_Main 

Purpose_WpnsSystem_Main 

MaxElevation_WpnsSystem_Main 

MinDepression_WpnsSystem_Main 

T  raverse_WpnsSystem_Main 
PositionOnVehic!e_WpnsSystem_Main 
TypeAmmunition  WpnsSystem_Main 

APFSDS 

HEAT-FS 

HED-T 

HE-FRAG 

Smoke 

QtyAmmunition_WpnsSystem_Main 

Type_WpnsSystem_Seconctary 

Purpose_WpnsSystem_Secondary 

MaxEIevation_WpnsSystem_Secondary 

MinDepression_WpnsSystem„Secondary 

T  raverse_WpnsSystem_Secondary 

PositionOnVehicle^WpnsSystem_Secondary 

TypeAmmunition„WpnsSystem_Secondary 

QtyAmmunition_WpnsSystem_Secondary 

Type_WpnsSystem_Tertiary 

Purpose_WpnsSystem_Tertiary 

Max_Elev_WpnsSystem_Tertiary 

Min_Depression_WpnsSystem_Tertiary 

T  raverse_WpnsSystem_Tertiary 
PositionOnVehicle_WpnsSystem_Tertiary 
Type_Ammunition_WpnsSystem_Tertiary 
Qty_Ammunltlon_WpnsSystem_Tertiary 

SmokeLaying 

Thickness_AnTior_FrontUpper 

Thickness_Annor_FrontLower 

Thickness_Aimor„Side  Upper 

Thickness_Armor_SideLower 

Thickness_Armor_RearUpper 

Thickness_Armor_RearLower 

Thickness_Aimor_TopTurret 

Thickness_Armor_TopHull 

Thickness_Armor_BellyFront 

Thickness_Armor_BeIlyRear 

Thickness_Armor_TurretFront 

Thickness_Armor_TurretSide 

Type^CollectiveNBCProtectionSystem 

FireControlSystem 

FireSuppressionSystem 

FireControlSystemController 

Glacis_Front_Upper 

Glacis_Front_Lower 

Glacis_Side_Upper 

GIacis_Side„Lower 

Glacis_Rear_Upper 

Glacis_Rear_Lower 

Targets 

Shoots 

Intercepts 

Occupy  Battle  Position 

Figure  A-112a.  Land  vehicle-  Figure  A-112a.  Land  vehicle¬ 
fighting  attributes.  fighting  attributes. 


Carrier 

Carrier 

Type_Carrier 

Objects  of  this  class  will  specialize 

Units_Carried 

inherited  methods 

ltem_Carried 

Figure  A-113a.  Carrier  attributes.  Figure  A-113b.  Carrier  methods. 


A-59 


Figure  A-114a.  GP  cargo 
attributes. 


Figure  A-114b.  GP  cargo 
methods. 


Personnel 

T roopCompartment_Size 
TroopCompartment_Exposure 
TroopCompartment__AccessDoors 
Size_T  roopCompartment_Access  Doors 
T  roopCompartmentObservationPorts 
TroopCompartmentFirIngPorts 
MaxTroopCapacity 
SpecializedPurpose 


Figure  A-115a.  Personnel 
attributes. 


Figure  A-115b.  Personnel 
methods. 


Figure  A-116a.  Weapon  attributes.  Figure  A-116b.  Weapon  methods. 


Figure  A-117a.  Sensor  attributes.  Figure  A-1 17b.  Sensor  methods. 
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Recovery 


Capacity_FreewheelTowing 

Capaclty_ShedTowing 

Type_TowPoint 

Capacity_TowPoint 

Locatlon_TowPoint 

Type_CraneSystem 

Location_CraneSystem 

Capacity_CraneSystem 

MaxHeight_CraneSystem 

Type_Wlnch 

Location_Winch 

Capacity_Winch 

Type^Blade 

Location_Blade 


Recovery 


Lift 

Tow 

Push 

Repair 


Figure  A-118a.  Recovery  Figure  A-118b.  Recovery 

attributes.  methods. 


SP  Artillery 

SP  Artillery 

Type_Carriage 

Objects  of  this  class  will  specialize 

Type_MainWpnSystem 

Type^Stabilization 

Type_RecoilSystem 

Type_LoadingSystem 
Type_Supporting_Vehicle 
CombinedLength_TravelLock 
ConnbinedLength_Ope  rational 

inherited  methods 

Figure  A-119a.  SP  artillery 

Figure  A-11 9b.  SP  artillery 

attributes. 

methods. 

Tank 

Tank 

Type_Hull 

Tracks 

Location_MainGun_AmmoStowage 

Calculates  Range 

Type_Loader 

Selects  Ordnance 

Load  Ordnance 

Figure  A-120a.  Tank  attributes.  Figure  A-120b.  Tank  methods. 
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Figure  A-1 21 .  Engineering. 


Engineering  Equipment 

Engineering  Equipment 

Roadworthy 

Make 

MissionArea 

Destroy 

MissionArea_Services 

Repair 

Figure  A-122a.  Engineering  Figure  A-122b.  Engineering 

equipment  attributes.  equipment  methods. 


Combat  Engineering  Equipment 

Combat  Engineering  Equipment 

Armored 

Objects  of  this  class  will  specialize 
inherited  methods 

Figure  A-123a.  Combat 
engineering  equipment 
attributes. 


Figure  A-1 23b.  Combat 
engineering  equipment 
methods. 


Mine  Layer 


Mine  Layer 


Conveyor 

Furrower 

Scraper 


Figure A-1 23c.  Minelayer 
attributes. 


Figure  A-1 23e.  ACE  attrib¬ 
utes. 


Figure  A-123g.  CEV  attributes. 


Bridging  Equipment 

Positionability 

Assoclated_Positioning_Equipment 

Combat„Environment 

Recovery_Method 

Associated_Recovery_Equipment 

Figure  A-1 24a.  Bridging 
equipment  attributes. 

Transporter 

Associated_Bndge/RaftSys 

Launch/Emplacement_Speed 

Launch/Emplacement_Method 


Figure  A-125a.  Transporter 
attributes. 


Emplaces  Mines 
Digs  Furrow 
Arms  Mines 
Dispenses  Mines 
Creates  Minefields 


Figure A-123d.  Minelayer 
methods. 


Figure  A-123f.  ACE  methods. 


Figure  A-123h.  CEV  methods. 


Figure  A-1 24b.  Bridging 
equipment  methods. 


Figure  A-125b.  Transporter 
methods. 
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MethodEmployment 

FloatBay_Width 

FloatBay_RoadwayWidth 

FloatBay_Length 

FloatBay_LiftCapacity 

Assemble  Draft_Capacity 

EndBay_Length 

EndBay_NumberRequired 

EndBay_NumberAvailab!e 

Assemble  Draft_Confi  gyration 

Propulsion 

Associated_PropulsionSystem 

MaxGradient_Nearshore 

MaxGradienLFarshore 

MinDepth^Nearshore 

MinDepth_Farshore 

MaxSpeed_Current 

MaxSpeed_Raft 

AssembledBridge_Capacity 

AssembledBridge^Configuration 


Figure  A-1 26a.  Raft  attributes. 


Bridge 

Configuration 

SpanSection_Width 

SpanSection_RoadwayWldth 

SpanSection_Length 

SpanSection_LiftCapaclty 

RampSection_Length 

RampSection_NumberRequired 

AssembledBrldge_Length 

BridgeCapacity 

BridgeConfiguration 

Dlrection_DedicatedTrafflc 

MaxGradient_AccessBank 

MaxGradienLEgressBank 

MaxDepth_Obstacle 

Obstacle  Bottom_Composition 

MaxCurrent_WaterObstac!e 


Figure  A-1 27a.  Bridge  attributes. 


Figure  A-1 26b.  Raft  methods. 


Figure  A-1 27b.  Bridge  methods. 


Figure  A-1 28a.  Construction 
equipment  attributes. 


Figure  A-1 28b.  Construction 
equipment  methods. 


Backhoe 

MaxCapacity_BuckeLCube 

MaxCapacity_BuckeLWeight 

Bucket_Width 

Bucket_Depth 

Operating_Speed 

Figure  A-1 29a.  Backhoe  attributes. 

Paving  Machine 

•  Pavement_Width 

PavemenLThickness 

Pavementl  Material 

Operating_Speed 

PavemenLMateriaLComsumptionRate 

Figure  A-130a.  Paving  machine 
attributes. 

Pile  Driver 

Drlver_Height 

Driver_Weight 

Driver_Drop 

Driver_GuideCircumference 

MaxLength_Piiings 

MaxCircumference_Pilings 

MinLength_Pilings 

MinCircumference_PiIings 

MaxHeight_Pilings 

MinHeight_Pilings 

Figure  A-131a.  Pile  driver 
attributes. 

Grader 

MaxCapacity_Bucket_Cube 

Width_Bucket 

MaxDepth_Bucket 

Operating  Depth_Bucket 

Figure  A-1 32a.  Grader  attributes. 

Bucket  Loader 

MaxCapacity_Bucket_Cube 

MaxCapacity_Bucket_Weight 

Width_Bucket 

MaxDepth_Bucket 

OperatingDepth_Bucket 

LiftHeight_Bucket 

Figure  A-133a.  Bucket  loader 
attributes. 


Backhoe 

Dig 

Figure  A-1 29b.  Backhoe  methods. 

Paving  Machine 

Pave 

Consume  Paving  Material 

Figure  A-1 30b.  Paving  machine 
methods. 

Pile  Driver 

Drive  Piles 

Consumes  Piles 

Figure  A-1 31b.  Pile  driver 
methods. 

Grader 

Grade 

Level 

Scrape 

Figure  A-1 32b.  Grader  methods. 

Bucket  Loader 

Fills 

Move  Material 

Lift  Material 

Load  Material 

Figure  A-1 33b.  Bucket  loader 
methods. 
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Crane 

Crane 

Max_Capacity_Bucket_Cube 

Lift 

Max_OperatingDepth 

Max_OperatingHeight 

Max_WeightLlfted 

MovementRange  • 

Move 

Figure  A-1 34a.  Crane  attributes. 

Figure  A-1 34b.  Crane  methods. 

Bulldozer 

Bulldozer 

MaxCapacity_Blade_Cube 

MaxCapacity_Blade_Weight 

Width^Blade 

MaxDepth_B!ade 

Ope  rati  ngDepth_Blade 

LlftHeight_Biade 

Move  Material 

Figure  A-1 35a.  Bulidozer  attributes. 

Figure  A-1 35b.  Buildozer  methods. 

Dumptruck 

Dumptruck 

MaxCapacity__Cube 

Moves  Material 

MaxCapacity_Weight 

Dump_Type 

Dumps  Material 

Figure  A-136a.  Dumptruck  attributes.  Figure  A-136b.  Dumptruck  methods. 


Concrete  Mixer 

Concrete  Mixer 

Capacity_Cube 

Mix  Concrete 

Consumes  Material 

Figure A-1 37a.  Concretemixer  Figure A-137b.  Concretemixer 

attributes.  methods. 


Ditching  Machine 

Ditching  Machine 

Cut_Width 

Dig  Ditch 

Cut_Depth 

Ditching_Speed 

Figure  A-1 38a.  Ditching  machine  Figure  A-1 38b.  Ditching  machine 

attributes.  methods. 
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Figure  A-139.  Transport. 


Transport 


Transport 


Type_Cab 
Location  Cab 


Run  Route 


Figure  A-1 40a.  Transport 
attributes. 


Figure  A-1 40b.  Transport  methods. 


CP  Cargo  Carrier 

Location_Steering 

Location_CargoArea 

Type_CargoArea 

Cover_CargoArea 

Associatecl_ShelterSystem 

lntenciedCargo_Type 

ActualCargo_Type 

MaxQuantity_Cargo 

ActualQuantity_Cargo 

MaxWeight_Cargo 

ActualWeight_Cargo 

MaxWidth_Cargo 

ActualWidth_Cargo 

MaxHeight_Cargo 

ActualHeight^Cargo 

MaxLength_Cargo 

ActuaILength_Cargo 

Height_CargoB  ed 

Number_AccessDoor 

Location^AccessDoor 

Width_AccessDoor 

Helght_AccessDoor 


CP  Cargo  Carrier 

Objects  of  this  class  will  specialize 
inherited  methods. 


Figure  A-1 41  a.  GP  cargo  carrier 
attributes. 


Figure  A-141b.  GP  cargo  carrier 
methods. 
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Bus 

Bus 

Location  Steering 

Objects  of  this  class  will  specialize 

MaxNumber_Passengers 

ActualNumber_Passengers 

Number_AccessDoor 

Location_AccessDoor 

Width^AccessDoor 

Height.AccessDoor 

Number^EmergencyDoor 

Nunnber_Window 

Associated_Equipment 

inherited  methods. 

Figure  A-142a.  Bus  attributes.  Figure  A-142b.  Bus  methods. 


Car 

Car 

Location_Steering 

Car_Type 

MaxNumber_Passengers 

ActualNumber_Passengers 

lntended_Passengers 

ActuaLPassengers 

Number^Door 

Number_Window 

Associated_Equipment 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-143a.  Car  attributes. 

Figure  A-1 43b.  Car  methods. 

Truck 

Truck 

Locatlon_Steering 

Location_CargoArea 

Type_CargoArea 

CargoArea_Cover 

Associated_ShelterSystem 

lntendedCargo_Type 

ActualCargo^Type 

MaxQuantity_Cargo 

ActualQuantity_Cargo 

MaxWeight_Cargo 

ActualWeight^Cargo 

I\/laxWidth_Cargo 

ActualWidth_Cargo 

MaxHeight_Cargo 

ActualHeight_Cargo 

MaxLength_Cargo 

ActualLength_Cargo 

HeighLCargoBed 

Number_AccessDoor 

Location_AccessDoor 

Width_AccessDoor 

Height_AccessDoor 

Associated_Trailer 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-144a.  Truck  attributes. 

Figure  A-1 44b.  Truck  methods. 

GP  Cargo 

GP  Cargo 

Location_Steering 

Objects  of  this  class  will  specialize 

inherited  methods. 

Figure  A-145a.  GP  cargo  attributes.  Figure  A-145b.  GP  cargo  methods. 
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Ambulance 


Ambulance 


Location_Steering 

Capacity_Lltters 

ActuaLLitters 

Associatecl_Medica!Technician 

Associated_EMSEquipment 

EmergencyMarkings 


Figure  A-1 46a.  Ambulance 
attributes. 


Objects  of  this  class  will  specialize 
inherited  methods. 


Figure  A-146b.  Ambulance 
methods. 


Location_Steering 

PriorContami  natlon_Status 

PriorContamination_Type 

CargoCompatibility 

Location_Pump 

Capacity_Pump 

Number_Spigot 

Location_Spigot 

Capacity__Spigot 

CombinedCapacity_Spigot 

Number_ServiceHatch 

Size_Service  Hatch 

Length_Associated_Hose 

Dlameter_Associated_Hose 

Filltime_Minimum 

Dumptime_Minimum 

FIIItime_Actual 

Dumptime_Actual 


Figure  A-1 47a.  Tanker  attributes.  Figure  A-147b.  Tanker  methods. 


Location_Steering 

MaxNumber_Passengers 

Actual  Number_Passengers 

Number_Door 

Number_EmergencyDoor 

Number_Window 

CargoArea_Slze 

IntendedCargo^Type 

Actual  Cargo_Type 

MaxQuantity_Cargo 

ActualQuantity_Cargo 

MaxWeight_Cargo 

ActualWeight_Cargo 

MaxWidth_Cargo 

ActualWidth_Cargo 

MaxHeighLCargo 

ActualHeight_Cargo 

MaxLength_Cargo 

Actual  Length_Cargo 


Figure  A-1 48a.  Van  attributes. 


Figure  A-1 48b.  Van  methods. 


Tractor 

Tractor 

T  railerCoupling_Type 

Objects  of  this  class  will  specialize 

Associated_Trailer„Type 

Associated.!  railer.Actual 
MaxCapacity.Towing 

Number.Door 

Width_Door 

Height.Door 

inherited  methods. 

Figure  A-149a.  Tractor  attributes.  Figure  A-149b.  Tractor  methods. 


Trailer 

Trailer 

TrailerCoupling_Type 

Associated_Primemover_Type 

Associated_Primemover_Actua( 

Location.CargoArea 

Type.CargoArea 

CargoArea.Cover 

Associated.ShelterSystem 

IntendedCargo.Type 

MaxQuantity_Cargo 

ActualQuantity.Cargo 

MaxWeight.Cargo 

ActualWeight_Cargo 

MaxWidth.Cargo 

ActualWidth_Cargo 

MaxHeight.Cargo 

ActualHeight.Cargo 

MaxLength.Cargo 

ActualLength.Cargo 

Height.CargoBed 

Number.Door 

Location_Door 

Width.Door 

Height.Door 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-150a.  Trailer  attributes. 

Figure  A-1 50b.  Trailer  methods. 

Towed  Weapon  System 

Towed  Weapon  System 

T  railerCoup!ing_Type 

Objects  of  this  class  will  specialize 

Associated.Primemover.Type 

inherited  methods. 

Associated.Primemover.Actual 

Associated.WeaponSystem 

Figure  A-151a.  Towed  weapon  Figure  A-151b.  Towed  weapon 

system  attributes.  system  methods. 
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Figure  A-152.  Communications  subtree. 


Communications 

Communications 

ECCM 

Carries  Information 

Frequency  Classification 

Bandwidth 

Spread  Spectrum 

Frequency  Hopping 

Encryption  Transmission 

Encryption  Message  Product 

Figure  A-1 53a.  Communications  Figure  A-153b.  Communications 

attributes.  methods. 
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Communication  Equipment 

Communication  Equipment 

Status 

Send 

Location 

Receive 

Method  of  Transmission: 

Converts 

Voice 

Deconverts 

FSK 

Encrypt 

Optical 

Mechanical 

Mode  of  Transmission: 

Duplex 

Half  duplex 

Simplex 

Security 

Decrypt 

Figure  A-154a.  Communication  Figure  A-154b.  Communication 

equipment  attributes.  equipment  methods. 


Communication  Network 

Communication  Network 

State  of  Connectivity 

Area  Boundary 

Security 

Mode  of  Connectivity 

RF 

Hardwire 

Fiber  Optic 

Line  of  Sight 

Over  the  Horizon 

Connects  Subscribers 

Relays 

Figure  A-1 55a.  Communication 

Figure  A-155b.  Communication 

network  attributes. 

network  methods. 

Node 

Node 

Location 

Objects  of  this  class  will  specialize 

Status 

Satellite  Communications 

Transmitter 

Receiver 

inherited  methods. 

Figure  A-1 56a.  Node  attributes. 

Figure  A-156b.  Node  methods. 

RF  Transceiver  Radio 

RF  Transceiver  Radio 

Location 

Objects  of  this  class  will  specialize 

Status 

inherited  methods. 

Portability 
Frequency 
Equipment  Type: 
UHF 
VHF 
SHF 

Antenna  Type 
Antenna  Height 


Figure  A-157a.  RF  transceiver  Figure  A-157b.  RF  transceiver 

radio  attributes.  radio  methods. 
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Telephone 

Telephone 

Fixed 

Mobile 

Portable 

Parkhill 

Ring 

Figure  A-158a.  Telephone  attributes. 

Figure  A-1 58b.  Telephone  methods 

Commerciaf  Radio/TV 

Commercial  Radio/TV 

Geographic  Location 

Call  Sign 

Channel  Number 

Frequency 

Satellite  Link 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-1 59a.  Commercial 
radioTV  attributes. 

Figure  A-1 59b.  Commercial 
radioTV  methods. 

Amateur  Radio 

Amateur  Radio 

Geographic  Location 

Antenna  Height 

Frequency 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-160a.  Amateur  radio 
attributes. 

Figure  A-160b.  Amateur  radio 
methods. 

Communication  Computer  Workstation 

Communication  Computer  Workstation 

Name/Designator 

Storage  Capacity 

CPU  Type 

CPU  Frequency 

Monitor  Type: 

Color 

Monochrome 

Monitor  Screen  Size 

Portability 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-1 61  a.  Communication 
computer  workstation  attributes. 

Figure  A-1 61b.  Communication 
computer  workstation  methods. 

Teletype 

Teletype 

Name/Designator 

Ring 

Figure  A-1 62a.  Teletype  attributes. 

Figure  A-1 62b.  Teletype  methods. 

Link 

Link 

Location 

Status 

Fiberoptic  Multiplex 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-1 63a.  Link  attributes.  Figure  A-163b.  Link  methods. 
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Courier 


Courier 


Military 

Civilian 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-1 64a.  Courier  attributes. 

Figure  A-164b.  Courier  methods. 

Relay 

Relay 

Location; 

Air 

Ground 

Satellite 

Frequency  Receive 

Frequency  Transmit 

Equipment  Type 

Type  of  Relay: 

Automatic 

Manual 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-1 65a.  Relay  attributes. 

Figure  A-165b.  Relay  methods. 

Communication  Line 

Communication  Line 

Objects  of  this  class  will  specialize 

Inherited  methods. 

Connectivity  Mode: 

Fiber  Optic 

Copper 

Radio  Frequency 

Figure  A-1 66a.  Line  attributes. 

Figure  A-1 66b.  Line  methods. 

FiaureA-167.  Countermeasures. 


Countermeasures 


Countermeasures 


Type 

Spectrum 

Position 


Figure  A-168a.  Countermeasures 
attributes. 


Prairie  Air/Masker  Belts 

Cycle  Time 
Number  of  Belts 


Figure  A-169a.  Prairie  air/masker 
belts  attributes. 


Visual/Optical 

Target  Size 
Occlusion 
Height  of  Eye 


Figure  A-1 70a.  Visual/optical 
attributes. 


Camouflage 

Color 

Style 

.  Size 

Amount 

Figure  A-1 71  a.  Camouflage 
attributes. 


Smoke 

Generator 

Amount 


Figure  A-172a.  Smoke  attributes. 


Decoys 

Deployment/Launch  Mode 


Figure  A-173a.  Decoys  attributes. 


Flotsam/Jetsom 

Material  Content 


Deceive 

Manipulate 

Confuse 


Figure  A-1 68b.  Countermeasures 
methods. 


Prairie  Air/Masker  Belts 


Dispense  Bubbles 
Masks  Sound 


Figure  A-1 69b.  Prairie  air/masker 
belts  methods. 


Visual/Optical 

Objects  of  this  class  will  specialize 
inherited  methods. 


Figure  A-1 70a.  Visual/optical 
attributes. 


Camouflage 

Blocks 

Figure  A-1 71b.  Camouflage 
methods. 


Smoke 


Obscure 


Figure  A-1 72b.  Smoke  methods. 


Decoys 


Launch 

Provides  False  Information 


Figure  A-1 73b.  Decoys  methods. 


Flotsam/Jetsom 


Float 

Drift 


Figure  A-1 74a.  Flotsam/jetsom  Figure  A-1 74b.  Flotsam/jetsom 

attributes.  methods. 
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Towed  Array 

Radiate 

Figure  A-175b.  Towed  array 
methods. 

Flares 

Burn 

Figure  A-176b.  Flares  methods. 

Underwater  Acoustic 

Makes  Noise 

Figure  A-177b.  Underwater 
acoustic  methods. 

Mock-Ups 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-178b.  Mock-ups  methods. 

Corner  Reflectors 

Reflect 

Towed  Array 

Length 

Frequency 

Type 

Electrical 

Mechanical 

Power  Output 

Noise  Output 

Effective  Range 

Figure  A-175a.  Towed  array 
attributes. 

Flares 

Source  Level 

Launch  Method 

Life 

Figure  A-176a.  Flares  attributes. 

Underwater  Acoustic 

Source  Level 

Trailing  Length 

Modulation 

Codes 

Depth 

Launch  Method 

Figure  A-177a.  Underwater 
acoustic  attributes. 

Mock-Ups 

Size_Unassembled 

Size_Assembled 

Weight 

Type 

TimeToAssemble 

Materials 

Figure  A-1 78a.  Mock-ups 
attributes. 

Corner  Reflectors 

Size 

Location 

Figure  A-179a.  Corner  reflectors  Figure  A-179b.  Corner  reflectors 

attributes.  methods. 
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Chaff 

Chaff 

Spectrum 

Dispenses 

Burst  Size  (radar  cross  section) 

Reflects 

Amount/Number  of  Bursts 

Figure  A-1 80a.  Chaff  attributes.  Figure  A-1 80b.  Chaff  attributes. 


Jammers 

Jammers 

Power 

Detect 

Azimuth  Resolution 

Locate 

Pulse  Analysis  Parameters 

Sensitivity 

Antenna  Type/Parameters 

Effective  Range 

Effective  Bandwidth 

Match  Frequency 

Transmit 

Library 

Memory 

Receiver  Type 

Figure  A-1 81a.  Jammers  attributes.  Figure  A-181b.  Jammers  methods. 


Figure  A-182.  Sateiiite  class. 


Satellite 

Sateiiite 

Status 

Moves 

Location 

Rotate 

Synchronous  Orbit 

Revolve 

Near  Polar  Orbit 

Generate  Power 

Polar  Orbit 

Rendezvous 

Controllable  Orbit 

Transmit 

Aircraft  Boost  Launch 

Receive 

Heavy  Vehicle  Boost  Launch 

Collect 

Recoverable  Vehicle  Launch 

Time  Limited 

Power  Limited 

Sensor  Resources  Limited 

Solar 

Battery 

Nuclear 

Lifespan 

Remaining  Life  Expectancy 

Weight 

Deploys  On-board  Equipment 

Launch  Date 

Ephemeris 

Fiaure  A-1 83a.  Satellite  attributes.  Fiaure  A-1 83b.  Satellite  methods. 
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Active  Passive 


A-78 


Figure  A-184.  Sensor  subtree. 


Sensor  Class 

Sensor  Class 

Function 

Detect 

Size  (dimensions) 

Locate 

Weight 

Identify 

Power 

Track 

Operating  Spectrum  (band) 

Report 

Operating  Ranges  (environmental  parameters) 

Analyze 

Update  Rates 

Arcs  of  Primary  and  Secondary  Operation 

Blind  Areas 

Wave  Propagation 

ECCM 

Status 

Frequency 

Location 

Exchange  Data 

Figure  A-1 85a.  Sensor  class  Figure  A-1 85b.  Sensor  class 

attributes.  methods. 


Active  Class 

Active  Class 

Counter-Detection  Range 

ECCM 

Target  Range 

Target  Bearing 

Target  Aspect 

Power/Source  Level 

Emit 

Figure  A-1 86a.  Active  class  Figure  A-186b.  Active  class 

attributes.  methods. 


Active  Sonar  and  Underwater  Sound 

Active  Sonar  and  Underwater  Sound 

Type 

Distortion 

Load 

Duty  Cycle 

Linearity 

Gain 

Sensitivity 

Range 

Range  Accuracy 

Bearing  Accuracy 

Bearing  Resolution 

Auto  Tracking 

Channels 

Tracking  Parameters 

Doppler  Resolution 

Beams 

Pulse  Length 

Staves 

Directivity  Index 

Transducer  Type/Number 

Hydrophone  Type/Number 

Depth 

Determine  Sound  Velocity  Profile 

Figure  A-1 87a.  Active  sonar  and  Figure  A-1 87b.  Active  sonar  and 

underwater  sound  attributes.  underwater  sound  methods. 
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Radar 

Radar 

Beam  Characteristics 

PRF 

Pulse  Width 

Antenna  Characteristics  (size,  weight,  wind  loading) 
Gain 

Modulation 

Processing  Methods 

Polarization 

Objects  of  this  class  will  specialize  inherited  methods. 

Figure  A-1 88a.  Radar  attributes. 

Figure  A-1 88b.  Radar  method 

s. 

Passive  Class 

Passive  Class 

Type 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-1 89a.  Passive  class 
attributes. 

Figure  A-1 89b.  Passive  class 
methods. 

Passive  Sonar  and  Underwater  Sound 

Passive  Sonar  and  Underwater  Sound 

Linearity 

Gain 

Sensitivity 

Bearing  Accuracy 

Bearing  Resolution 

Auto  Tracking 

Channels 

Doppler  Resolution 

Beams 

Staves 

Directivity  Index 

Hydrophone  Type/Number 

Depth 

Objects  of  this  class  will  specialize  . 

Inherited  methods. 

Figure  A-1 90a.  Passive  sonar  and 
underwater  sound  attributes. 

Figure  A-1 90b.  Passive  sonar  and 
underwater  sound  methods. 

Seismic 

Seismic 

Source  Level 

Duration 

Sensitivity 

Parameter  Measurement 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-1 91  a.  Seismic  attributes. 

Figure  A-1 91  b.  Seismic  methods. 

Magnetic 

Magnetic 

Sensitivity 

Background  Noise 

Measurement  Range 

Slant  Range 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-1 92a.  Magnetic  attributes. 

Figure  A-1 92b.  Magnetic  methods. 
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NBC 

NBC 

Parameter  Measurement 

Objects  of  this  class  will  specialize 

Sensitivity 

Inherited  methods. 

Figure  A-193a.  NBC  attributes.  Figure  A-193b.  NBC  methods. 


ESM 

ESM 

Type 

Azimuth  Resolution 

Pulse  Analysis  Parameters 

Sensitivity 

Antenna  Type/Parameters 

Effective  Range 

Effective  Bandwidth 

Antenna 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-194a.  ESM  attributes. 

Figure  A-1 94b.  ESM  methods. 

Visual  (Optronics) 

Visual  (Optronics) 

Type 

Frequency  Range 

Field  of  View 

Resolution 

Sensitivity 

Image  Output  Format 

Interfaces 

Aspect  Ratio 

Stabilization 

Magnification 

Elevation 

Scanning 

Photoelectric 

Photoconductive 

Photoelectromag  netic 

Objects  of  this  class  will  specialize 
inherited  methods. 

Figure  A-1 95a.  Visual  (optronics) 
attributes. 

Figure  A-1 95b.  Visual  (optronics) 
methods. 

IR  Camera 

IR  Camera 

Micron 

Type 

Frequency  Range 

Field  of  View 

Resolution 

Sensitivity 

Image  Output  Format 

Interfaces 

Aspect  Ratio 

Stabilization 

Magnification 

Elevation 

Scanning 

Produce  Physical  Product 

Figure  A-1 96a.  IR  camera 
attributes. 

Figure  A-196b.  IR  camera 
methods. 
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Navigation/GPS 


Type  (GPS/LORAN/OMEGAyTERCON,  etc.) 

Orbit  Type 

Clock 

Life 

Field 

Position 

Altitude 

Coordinate  System 
Accuracy 
Magnetic  Variation 
Map  Datum 
Regional  Identifiers 
Data  Interface 
Port  Configuration 


Navigation/GPS 


Objects  of  this  class  will  specialize  inherited 
methods. 


Figure  A-1 97a.  Navigation/GPS 
attributes. 


Figure  A-197b.  Navigation/GPS 
methods. 


Figure  A-1 98.  Weapon  system. 


Weapon 


Location 

Status 


Figure  A-1 99a.  Weapon  attributes. 


Figure  A-1 99b.  Weapon  methods. 
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Missile/Rocket 

Missiie/Rocket 

Warhead  Type 

Guide  Self 

Warhead 

Launch 

Dimensions 

Fly 

Weight 

Arrive 

Mobility 

Destruct 

Range 

Max  Speed 

Guidance  System 

Weapon  Platform 

CEP 

Arm  Self 

■ 

Figure  A-200a.  Missile/rocket 

Figure  A-200b.  Missile/rocket 

attributes. 

methods. 

Bomb 

Bomb 

Type 

Fall 

Dimensions 

Arrive 

Weight 

Destruct 

Guidance 

Arm  Self 

Detect 

Figure  A-201  a.  Bomb  attributes. 

Figure  A-201  b.  Bomb  methods. 

Mine 

Mine 

Size 

Move 

Type 

Detect 

Acoustic 

Destruct 

Contact 

Time  Fuse 

Electronic 

Placement  Method 

Placement  Depth 

Moored 

Lifetime 

Target  Selectivity 

Arm  Self 

Figure  A-202a.  Mine  attributes. 

Figure  A-202b.  Mine  methods. 

Torpedo 

Torpedo 

Speed 

Destruct 

Range 

Warhead 

Size 

Guidance 

Launch  Platform 

Power  Plant 

Weight 

Arm  Self 

Figure  A-203a.  Torpedo  attributes. 

Figure  A-203b.  Torpedo  methods. 

Gun 

Gun 

Size 

Weight 

Range 

Reload 

Figure  A-204a.  Gun  attributes.  Figure  A-204b.  Gun  methods. 
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Physical . 


A-84 


Figure  A-205.  Natural  environment 


Region 

Region 

Location 

Get/Set  Location 

Area 

Get/Set  Area 

Boundaries 

Get/Set  Boundaries 

Figure  A-206a.  Region  attributes. 

Figure  A-206b.  Region  methods. 

Soil  Cover 

Soil  Cover 

Type:  (one  or  some  of) 

Get/Set  Type 

Sand 

Get/Set  Friability 

Gravel 

Dirt 

Clay 

Rock 

Ice 

Snow 

Permafrost 

Friability 

Water  Absorption  Rate 

Get/Set  Water  Absorption  Rate 

Figure  A-207a.  Soil  cover  attributes. 

Figure  A-207b.  Soil  cover  methods. 

Open  Water 

Open  Water 

Depth 

Get/Set  Depth 

Potability 

Get/Set  Potability 

Navigability 

Get/Set  Navigability 

Flow  Direction 

Get/Set  Flow  Direction 

Flow  Rate 

Get/Set  Flow  Rate 

Islands 

Get/Set  Islands 

Figure  A-208a.  Open  water 

Figure  A-208b.  Open  water 

attributes. 

methods. 

Wetland 

Wetland 

Trafficability 

Get/Set  Trafficability 

Channels 

Get/Set  Channels 

Figure  A-209a.  Wetland  attributes. 

Figure  A-209b.  Wetland  methods. 

Forest 

Forest 

Type 

Get/Set  Type 

Density 

Get/Set  Density 

Trafficability 

Get/Set  T  rafficability 

Shelter 

Get/Set  Shelter 

Cover 

Get/Set  Cover 

Flammability 

Get/Set  Flammability 

Deciduous 

Get/Set  Deciduous 

Figure  A-210a.  Forest  attributes.  Figure  A-21  Ob.  Forest  methods. 
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Cane 

Density 

Trafficabillty 

Shelter 

Cover 

Figure  A-211a.  Cane  attributes. 
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Harvestable  Food  Value 
Harvestable  Food  Cost 
Passage  Constraints 


Figure  A-212a.  Cropland  attrib¬ 
utes. 


Plantation 


Crop 

Setting 


Figure  A-213a.  Plantation  attributes. 
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Depth 
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Estimated  Volume 


Figure  A-214a.  Aquifer  attributes. 


Watershed 


Average  Annual  Rainfall 
Average  Annual  Runoff 
Flood  Zone 
Exit 


Figure  A-215a.  Watershed  attributes. 
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Figure  A-21 6a.  Topography 
attributes. 


Cane 


Get/Set  Density 
Get/Set  Trafficabillty 
Get/Set  Shelter 
Get/Set  Cover 


Figure  A-211b.  Cane  methods. 


Cropland 

Get/Set  Type 

Get/Set  Harvestable  Food  Value 
Get/Set  Harvestable  Food  Cost 
Get/Set  Passage  Constraints 


Figure  A-21 2b.  Cropland  methods. 


Plantation 


Get/Set  Crop 
Get/Set  Setting 


Figure  A-21 3b.  Plantation  methods. 


Aquifer 

Get/Set  Depth 
Get/Set  Salinity 
Get/Set  Estimated  Volume 


Figure  A-21 4b.  Aquifer  methods. 


Watershed 


Get/Set  Average  Annual  Rainfall 
Get/Set  Average  Annual  Runoff 
Get/Set  Flood  Zone 
Get/Set  Exit 


Figure  A-21 5b.  Watershed  methods. 


Topography 

Get/Set  Plain 
Get/Set  Hill 
Get/Set  Mountain 
Get/Set  Desert 
Get/Set  Savannah 
Get/Set  Valley 
Get/Set  Basin  and  Range 
Get/Set  Mesa 
GeVSet  Subterranean 


Figure  A-21 6b.  Topography 
methods. 
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Ocean/Sea  Water 

Ocean/Sea  Water 

Depth 
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Visibility 
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Temperature 

Flow  Direction 

Flow  Rate 

Surface  Vegetation 

Get/Set  Depth 

Get/Set  Salinity 

Get/Set  Turbidity 

Get/Set  Visibility 

Get/Set  Swell 

Get/Set  Wave  Height 

Get/Set  Temperature 

Get/Set  Flow  Direction 

Get/Set  Flow  Rate 

Get/Set  Surface  Vegetation 

_ _ _ 

Figure A-21 7a.  Ocean/seawater 
attributes. 

Figure  A-21 7b.  Ocean/seawater 
methods. 

Sea  Bottom  Topography 

Sea  Bottom  Topography 

Seamounts 

Rolling 

Abyssal  Plain 

Trench 

Get/Set  Seamounts 

Get/Set  Rolling 

Get/Set  Abyssal  Plain 

Get/Set  Trench 

Figure  A-21 8a.  Sea  bottom 
topography  attributes. 

Figure  A-21 8b.  Sea  bottom 
topography  methods. 

Sea  Bottom  Fauna 

Sea  Bottom  Fauna 

Density 

Distribution 

Location 

Sound  Absoprtion 

Get/Set  Density 

Get/Set  Distribution 

Get/Set  Location 

Get/Set  Sound  Absoprtion 

Figure  A-21 9a.  Sea  bottom  fauna 
attributes. 

Figure  A-21 9b.  Sea  bottom  fauna 
methods. 

Sea  Bottom  Soil  Cover 

Sea  Bottom  Soil  Cover 

Type:  (one  or  some  of) 

Sand 

Gravel 

Rock 

Silt 

Coral 

Sound  Absorption 

Get/Set  Type 

Get/Set  Sound  Absorption 

Figure  A-20a.  Sea  bottom  soil 
cover  attributes. 

Figure  A-220b.  Sea  bottom  soil 
cover  methods. 

Littoral  Area 

Littoral  Area 

Area 

GetSet  Area 

Figure  A-221  a.  Littoral  area  Figure  A-221b.  Littoral  area  methods 

attributes. 
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Figure  A-222a.  Delta  attributes.  Figure  A-222b.  Delta  methods. 


Figure  A-223a.  Surf  zone  attributes.  Figure  A-223a.  Surf  zone 

attributes. 


Figure  A-224a.  Bay  attributes.  Figure  A-224b.  Bay  methods. 


Figure  A-224C.  Space  attributes.  Figure  A-224d.  Space  methods. 


Figure  A-225a.  Space  debris  Figure  A-225b.  Space  debris 

attributes.  methods. 


Figure  A-226a.  Asteroid  attributes.  Figure  A-226b.  Asteroid  methods. 
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Air 
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Temperature 

Get/Set  Temperature 

Flow  Direction 

Get/Set  Flow  Direction 

Flow  Rate 

Get/Set  Flow  Rate 

Level 

Get/Set  Level 
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Get/Set  Visibility 
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lono 

Visibility 

Figure  A-227a.  Air  attributes. 

Figure  A-227b.  Air  methods. 

Gas 
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Oxygen  Content 

Get/Set  Oxygen  Content 

Human-Adverse  Content 

Get/Set  Human- Ad  verse  Content 

Figure  A-228a.  Gas  attributes. 

Figure  A-228b.  Gas  methods. 
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Cloud 

Type 

Get/Set  Type 
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Get/Set  Lower  Ceiling 

Upper  Ceiling 

Get/Set  Upper  Ceiling 

Make  Up 

Get/Set  Make  Up 

Smoke 

Dust 

Steam 

Precipitation 

Figure  A-229a.  Cloud  attributes. 

Figure  A-229b.  Cloud  methods. 

Aerosol 

Aerosol 

Composition 

Get/Set  Composition 

Density 

Get/Set  Density 

Figure  A-230a.  Aerosol  attributes. 

Figure  A-230b.  Aerosol  methods. 

Precipitation 

Precipitation 

24-Hour  Rate 

Get/Set  24-Hour  Rate 

Short-Term  Rate 

Get/Set  Short-Term  Rate 

Form 

water/ice/hail/snow 

Get/Set  Form 

Figure  A-231a.  Precipitation 
attributes. 


Figure  A-231b.  Precipitation 
methods. 


Figure  A-232.  Non-human. 


Figure  A-233.  Artificial. 
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Figure  A-235.  Air  link  subclass. 
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Get/Set  High  Alt  Lower 
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Get/Set  Low  Alt  Upper 
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Figure  A-236a.  Air  way  attributes. 

Figure  A-236b.  Air  way  methods. 
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Get/Set  IFF  Code  on  Rtn  to  Force  Acft 

iFF  Code  on  Departure  Acft 

Get/Set  iFF  Code  on  Departure  Acft 

Figure  A-236C.  Air  corridor  Figure  A-236d.  Air  corridor 

attributes.  methods. 
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Engagement 

Get/Set  Target(s) 

Get/Set  Conventional/NBC 

Get/Set  Start  Condition(s) 

Get/Set  Planned  Duration 

Get/Set  Termination  Condition(s) 

Get/Set  Regional  Location 

Get/Set  OPFOR  Name 

Get/Set  OPFOR  Sensing 

Get/Set  OPFOR  Firepower 

Get/Set  OPFOR  Mobility 

Figure  A-238b.  Engagement 
methods. 

Air-Air 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technique(s):  (default  va!ue(s)) 

Get/Set  Weapon{s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 

Figure  A-239a.  Air-air  methods. 

Air-Gnd 

Get/Set  Tactic(s):  (default  value{s)) 

Get/Set  Technlque(s):  (default  value(s)) 

Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor{s):  (default  value(s)) 

Get/Set  Communicatlon(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  va!ue(s)) 

Figure  A-240b.  Air-ground 
methods. 

Air-Space 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technique(s):  (default  value(s)) 

Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communicatlon(s):  (default  va!ue(s)) 
Get/Set  Countermeasure{s):  (default  value(s)) 

Figure  A-241  b.  Air-space 
methods. 

Air-Subsurface 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technique(s):  (default  value(s)) 
Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countemneasure(s):  (default  value(s)) 
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OPFOR  Firepower 
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Figure  A-238a.  Engagement 
attributes. 

Air-Air 

Tactic(s):  (default  value(s)) 

Technique{s):  (default  value{s)) 

Weapon(s):  (default  value(s)) 

Sensor(s):  (default  value(s)) 
Communication(s):  (default  value(s)) 
Countermeasure(s):  (default  value(s)) 

Figure  A-239a.  Air-air  attributes. 

Air-Gnd 

Tactic(s):  (default  value{s)) 

Technique(s):  (default  value(s)) 

Weapon(s):  (default  value(s)) 

Sensor(s):  (default  value(s)) 
Communication(s):  (default  value(s)) 
Countermeasure(s):  (default  va!ue(s)) 

Figure  A-240a.  Air-ground 
attributes. 

Air-Space 

Tactic(s):  (default  value(s)) 

Technique(s):  (default  value(s)) 

Weapon{s):  (default  vaiue(s)) 

Sensor(s):  (default  value(s)) 
Communication(s):  (default  value(s)) 
Countermeasure(s):  (default  value(s)) 

Figure  A-241  a.  Air-space 
attributes. 

Air-Subsurface 

Tactic(s):  (default  value(s)) 

Technique(s):  (default  value(s)) 

Weapon(s):  (default  value(s)) 

Sensor(s):  (default  value(s)) 
Communication{$):  (default  value(s)) 
Countermeasure(s):  (default  value(s)) 

Figure  A-242a.  Air-subsurface 
attributes. 


Figure  A-242b.  Air-ground 
methods. 
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Air-Surface 

Tactic(s):  (default  value(s)) 
Technique(s):  (default  value(s)) 
Weapon(s):  (default  value(s)) 
Sensor(s):  (default  value(s)) 
Communlcatjon(s):  (default  value(s)) 
Countermeasure(s):  (default  value{s)) 


Air-Surface 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technlque(s):  (default  value(s)) 
Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 


Figure  A-243a.  Air-surface  attributes. 


Figure  A-243b.  Air-surface  methods. 


Gnd-Air 

Tactic(s):  (default  value (s)) 
Technique(s):  (default  value(s)) 
Weapon(s):  (default  value(s)) 
Sensor(s):  (default  value(s)) 
Communication(s):  (default  value(s)) 
Countermeasure(s);  (default  value(s)) 


Gnd-Air 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technique(s):  (default  value(s)) 
Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value (s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 


Figure  A-244a.  Ground-air 
attributes. 


Figure  A-244b.  Ground-air 
methods. 


Gnd-Gnd 

Tactic(s);  (default  value(s)) 
Technique(s):  (default  value(s)) 
Weapon(s):  (default  value(s)) 
Sensor(s):  (default  value(s)) 
Communication(s):  (default  value(s)) 
Countermeasure(s);  (default  value (s)) 


Gnd-Gnd 

Get/Set  Tactic (s):  (default  value (s)) 

Get/Set  Technlque(s):  (default  value(s)) 
Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 


Figure  A-245a.  Ground-ground 
attributes. 


Figure  A-245b.  Ground-ground 
methods. 


Gnd-Surface 
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Technique(s):  (default  value(s)) 
Weapon(s):  (default  value(s)) 
Sensor(s):  (default  value(s)) 
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Countermeasure(s):  (default  value (s)) 


Gnd-Surface 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technique(s):  (default  value(s)) 
Get/Set  Weapon(s):  (default  value(s)) 
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Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 


Figure  A-246a.  Ground-surface 
attributes. 


Figure  A-246b.  Ground-surface 
methods. 


Gnd-Space 

Tactic(s):  (default  value(s)) 
Technique(s):  (default  value(s)) 
Weapon(s):  (default  value(s)) 
Sensor(s):  (default  value(s)) 
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Countermeasure(s):  (default  value (s)) 


Gnd-Space 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technique(s):  (default  value(s)) 
Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value (s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 


Figure  A-247a.  Ground-space 
attributes. 


Figure  A-247b.  Ground-space 
methods. 
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Surf-Air 

Tactic{s):  (default  value(s)) 

Technlque(s):  (default  value(s)) 

Weapon(s):  (default  value(s)) 

Sensor(s):  (default  value (s)) 
Communication(s):  (default  value(s)) 
Countermeasure(s):  (default  value(s)) 

Figure  A-248a.  Surface-air 
attributes. 

Surf-Surf 

Tactjc(s):  (default  value(s)) 

Technique(s):  (default  value(s)) 

Weapon(s):  (default  value(s)) 

Sensor(s):  (default  value(s)) 
Communicatlon(s):  (default  vaiue(s)) 
Countermeasure(s):  (default  value(s)) 

Figure  A-249a.  Surface-surface 
attributes. 

Surf-Subsurf 

Tactic(s):  (default  value (s)) 

Technique(s):  (default  va!ue(s)) 

Weapon(s):  (default  value(s)) 

Sensor(s):  (default  value (s)) 
Connmunication(s):  (default  value(s)) 
Countermeasure(s):  (default  value(s)) 

Figure  A-250a.  Surface-subsurface 
attributes. 

Surf-Gnd 

Tactic(s):  (default  value(s)) 

Technlque(s):  (default  value(s)) 

Weapon(s):  (default  value(s)) 

Sensor(s):  (default  value(s)) 
Communication(s):  (default  value(s)) 
Countermeasure(s):  (default  value(s)) 

Figure  A-251a.  Surface-ground 
attributes. 

Subsurf-Air 

Tactlc(s):  (default  value(s)) 

Technique(s):  (default  value(s)) 

Weapon(s):  (default  value(s)) 

Sensor(s):  (default  value(s)) 
Communication(s):  (default  value(s)) 
Countermeasure(s):  (default  vaiue(s)) 

Figure  A-252a.  Subsurface-air 
attributes. 


Surf-Air 

Get/Set  Tact(c(s):  (default  value(s)) 

Get/Set  Technique(s):  (default  value(s)) 

Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communjcation(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 

Figure  A-248b.  Surface-air 
methods. 

Surf-Surf 

Get/Set  Tactlc(s):  (default  value(s)) 

Get/Set  Technique{s):  (default  value(s)) 

Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communlcation(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 

Figure  A-249b.  Surface-surface 
methods. 

Surf-Subsurf 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technique(s):  (default  value(s)) 

Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countenneasure(s):  (default  value(s)) 

Figure  A-250b.  Surface-subsurface 
methods. 

Surf-Gnd 

Get/Set  Tactic(s):  (default  va!ue(s)) 

Get/Set  Technique(s):  (default  value(s)) 

Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 

Figure  A-251b.  Surface-ground 
methods. 

Subsurf-Air 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technique(s):  (default  value(s)) 

Get/Set  Weapon(s);  (default  value(s)) 

Get/Set  Sensor (s):  (default  value (s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s);  (default  vajue(s)) 

Figure  A-252b.  Subsurface-air 
methods. 
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Subsurf-Gnd 

Subsurf-Gnd 

Tactic(s):  (default  value(s)) 
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Sensor(s):  (default  value(s)) 
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Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communication (s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value (s)) 

Figure  A-253a.  Subsurface-ground 
attributes. 

Figure  A-253b.  Subsurface-ground 
methods. 

Subsurf-Surf 

Subsurf-Surf 

Tactic(s):  (default  value(s)) 

Technjque(s):  (default  value{s)) 

Weapon(s):  (default  value(s)) 

Sensor(s):  (default  value(s)) 
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Countermeasure(s):  (default  value(s)) 
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Get/Set  Technique(s):  (default  value(s)) 

Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 

Figure  A-254a.  Subsurface-surface 
attributes. 

Figure  A-254b.  Subsurrface-surface 
methods. 

Subsurf-Subsurf 

Subsurf-Subsurf 

Tactic(s):  (default  value(s)) 
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Weapon (s):  (default  value(s)) 

Sensor(s):  (default  value(s)) 
Communication(s):  (default  value(s)) 
Countermeasure(s):  (default  value(s)) 

Get/Set  Tactic(s):  (default  value(s)) 

Get/Set  Technjque(s):  (default  value(s)) 

Get/Set  Weapon(s):  (default  value(s)) 

Get/Set  Sensor(s):  (default  value(s)) 

Get/Set  Communication(s):  (default  value(s)) 
Get/Set  Countermeasure(s):  (default  value(s)) 

Figure  A-255a.  Subsurface-  Figure  A-255b.  Subsurface- 

subsurface  attributes.  subsurface  methods. 
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APPENDIX  B:  SAMPLE  THREAD 


Appendix  B  demonstrates  how  the  classes  defined  in  appendix  A  can  be  used  to  model  a  specific 
operation.  It  also  shows  the  use  of  Event  Flows  and  State  Transition  Diagrams  to  model  behavior.  A 
description  of  the  thread  is  provided  below. 

This  operation  was  chosen  for  the  thread  due  to  its  realism  and  involvement  of  multiple  Services. 

It  is  not  a  highly  detailed  scenario,  but  is  provided  to  illustrate  the  use  of  the  taxonomy. 

B.1  THREAD  NARRATIVE 

An  element  of  the  82nd  Division  Airborne  Infantry  Battalion  is  in  contact  with  an  enemy  tank  pla¬ 
toon  (T64s)  that  poses  a  threat  to  Company  A  on  the  right  flank,  and  requires  immediate  Close  Air 
Support  (CAS).  (“Immediate”  in  this  context  has  the  specific  meaning  that  the  CAS  is  needed  now.) 
Air  resources  not  associated  with  the  Battalion  must  be  redirected. 

Present  with  the  Infantry  Battalion  is  an  Air  Force  Forward  Air  Control  (FAC)  officer.  The  Battal¬ 
ion  S3  directs  the  FAC  to  formulate  and  issue  an  immediate  air  support  request.  The  S3  identifies  the 
unit  in  contact,  its  location,  and  its  command  frequency,  as  well  as  the  character  of  the  target.  The 
FAC  needs  this  last  to  make  sure  the  right  kind  of  ordnance  is  onboard  the  aircraft. 

The  FAC  forwards  the  request  to  the  Tactical  Air  Control  Party  (TACP)  at  the  Infantry  Brigade 
level.  The  TACP  determines  there  is  no  Brigade-controlled  air  available  in  the  area.  The  TACP  then 
contacts  the  Division  TACP.  The  same  process  recurs:  the  Division  TACP  (lacking  available  air  in 
this  example)  contacts  the  Battlefield  Coordination  Element  (BCE)  at  the  XVIII  Corps.  (The  BCE  is 
an  integrated  Army/ Air  Force  element  at  Corps  Main  HQ.)  The  BCE  determines  that  a  flight  of  two 
Marine  AV-8Bs  have  been  assigned  to  him  for  just  such  a  purpose,  i.e.,  they  are  uploaded  with  Rock- 
eye,  an  anti-tank  ordnance. 

The  BCE  contacts  the  flight  leader  and  informs  him  of  the  mission,  directs  him  to  the  forward  air 
control  frequency  for  mission  assignment,  provides  the  call  sign,  and  assigns  a  Contact  Point  (CP). 

Then  the  BCE  sends  back  down  the  communications  chain  (BCE  to  Division  TACP  to  Brigade 
TACP  to  Battalion  FAC)  that  there  are  two  AV-8Bs  with  Rockeye  inbound,  and  tells  the  estimated 
time  of  arrival  at  the  CP. 

During  this  time,  the  FAC  relocates  as  close  to  the  Company  Commander  as  possible,  and  identi¬ 
fies  the  appropriate  Initial  Point  (IP)  and  a  Release  Point  (RP).  The  pilot  checks  in  with  the  FAC  at 
the  CP,  establishing  voice  communications.  The  FAC  gives  the  mission  briefing,  which  will  update 
the  pilots,  provide  run-in  and  release  headings,  pull-off  direction,  Time-On-Target  (TOT),  and  the 
method  to  be  used  to  mark  the  target. 

The  planes  then  execute  the  mission  and  return  to  base,  checking  out  with  everyone  with  whom 
they  checked  in,  reporting  the  FAC’s  estimate  of  Bomb  Damage  Assessment  (BDA). 

B.2  OT  THREAT  REPRESENTATION 

Figure  B-1  shows  the  flow  of  events,  represented  using  the  Martin/Odell  Event  Flow  notation.  Fig¬ 
ure  B-2  shows  the  state  diagram  for  the  mission  of  Forward  Air  Controller.  There  are  four  major 
states:  request  CAS,  prepare  to  engage,  state  mission,  and  estimate  BDA.  The  second  of  these,  pre¬ 
pare  to  engage,  has  three  substates:  relocate  to  Company  Commander;  establish  mission  IP  and  RP; 
and  await  pilot  contact. 
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Figure  B-2.  State  diagram  for  the  mission  of  the  Forward  Air  Controller. 

Figures  B-3.1  through  B-3.11  show  the  high  level  classes  and  objects  that  implement  this  scenario 
and  traces  the  high  level  Marine  Corps  thread.  Figures  B-4a  through  B-4c  show  complete  definitions 
for  the  requisite  objects. 


Figure  B-3.  Scenario  implementation  high  level  classes  and  objects. 


Figure  B-3.1.  Airborne  Corps  class. 


Figure  B-3.2.  Airborne  Division  class. 


Figure  B-3.3.  Numbered  Air  Force,  Control  and 
Reporting  Center  and  Fonvard  Air  Control  Post  classes. 


Figure  B-3.4.  Marine  Expeditionary  Force  class. 
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Note:  Marine  Aircraft  Wings  are  task  organized. 


Figure  B-3-5.  Marine  Aircraft  Wing  class. 
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AGENT 

^  . 

ORGANIZATION 

MARINE  EXPEDITIONARY  FORCE 

U.S.  MARINE  AIRCRAFT  WING 

MARINE  AIR  CONTROL  GROUP  ' 


Personnel 

Officers  (m)  203 

(n)  2 

Enlisted  (m)  2342 

(n)  15 

T/ONo.8600 


Airborne  DASC  1 

Radio  Set  452 

Radar  Bomb  Set  1 

Radar  Set  AN/TSQ-107  4 

TACAN  8 

Precision  Apch  Radar  4 

#TC  Tower  System  4 

Pedestal  Mounted  Stinger  60 

Stinger  Night  Sight  100 

Hawk  Launchers  16 

Radio  Set,  AN/GRA39  74 

Radar  Set,  AN/MPQ57  3 

Radar  Set,  AN/MPQ55  4 


Marine  Tactical  Air  Cmd  Sqdn 
Marine  Wing  Comm  Sqdn 
Light  Anti-Aircraft  Missile  Bn 
Low  Altitude  Air  Defense  Bn 
Marine  Air  Control  Sqdn 
Marine  Air  Support  Sqdn 
Marine  Air  Traffic  Control  Sqdn 
MAC6  Headquarters 


Figure  B-3.7.  Marine  Aircraft  Group  (Fixed 
Wing)  and  Marine  Attack  Squadron  classes. 


Figure  B-3.6.  Marine  Air  Control 
Group/Squadron  and  Marine  Air 
Support  Squadron  classes. 
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Aircraft 


Aircraft 


Type 

Change  Status 

Model 

Change  Speed 

Series 

Change  Course 

Crew 

Report  Status 

Location 

Take-off 

Unrefueled  Ferry  Range 

Fly 

Land 

Refuel 

Range  with  In-Flight  Refueling 

Max  Speed  -  Sea  Level 

Be  Maintained 

Cruise  Speed 

Rendezvous 

Fuel  Capacity 

Status 

Threat  Signature 

Min  T-0  Distance 

Service  Ceiling 

Min  Landing  Distance 

Length 

Height 

Fly  in  Formation 

Wingspan 

Wheelbase 

Max  Gross  T-0  Weight 

Max  Climb  Rate  at  Sea  Level 
Number  of  Engines 

Identification 

Country  of  Origin 

Country  of  Operation 

Max  Hover  Height 

Max  Hover  Weight 

Empty  Weight 

Scheduled  Maintenance 

Primary  Configuration  Code 

IFF  Code 

Figure  B-3.8.  Aircraft  attributes  and  methods. 
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Fighting 


Max  Climb  Rate 
"g"  Limits  +/- 
Aspect  Ratio 
Max  Speed  at  Altitude 
Max  Range  with  External  Tanks 
Combat  Ceiling 
External  Tank  Restrictions 
Combat  Air  Patrol  Endurance 
(at  distance) 

Aiming  System 

Hectronic  Countermeasures  Suite 
Cryptographic  Comm  Suite 
Radar  Warning  Receiver 
Head  Up  Display -yes/no 


Fighting 


Calculate  Max  Speed/AItitude 
Calculate  Max  Angle  of  Attack  at  Speed 
Evade/Avoid 


Figure  B-3.9.  Fighting  attributes  and  methods. 


Max  External  Stores 
Hi-Lo-Hi  Range 
Bombing  System 
Hellfire,  yes/no 
Maverick,  yes/no 
Sidewinder,  yes/no 
Mk  Series  Bombs,  yes/no 
Mk  Series  LGB,  yes/no 
Bullpup,  yes/no 
HARM,  yes/no 
Rockeye,  yes/no 
CBU59,  yes/no 
GATOR  Mines,  yes/no 
Laser  Spot  Tracker,  yes/no 


strafe 
Drop  Bomb 
Launch  Rockets 


Figure  B-3.10.  Attack  attributes  and  methods. 


AV-8 


AV-8A 


Outriggers 

Max  Vertical  T-OWt. 

Max  Vertical  Landing  Wt. 


AV-8B 


Add  Aircraft  Attributes 
Add  Rghting  Attributes 
Add  Attack  Attributes 
Type-Attack.  Vertical  T-0 
Model  -  8 
Series  -  B 
Crew -One 
Status  -  FMC 
Location  -  Airborne 
Identification  -  TOMCAT  13 
Wingspan -30'4* 

Aspect  Ratio  -  4 
Length  -  46'4* 

Height- 117  3/4' 

Wheelbase  - 170’  (outriggers) 

Empty  Wt  - 1 3,086  lbs. 

Max  Fuel  - 15,829  lbs. 

Max  Internal  -  7,759  lbs. 

Max  T-0  Wt- 31,000  lbs. 

Max  Landing  Wt  -  25,000  lbs. 

Max  Speed-Sea  Level  -  575  kts. 

Min  T-0  Distance  at  Max  GW  - 1 ,330  ft. 
Unrefueled  Ferry  Range  -  2,100  nm 
Max  External  Stores  -  9.200  lbs. 

Bombing  System  -  ARBS 

"g"  Limits  -  +7/-3 

Max  Speed  at  Altitude  -  605  kts. 

Combat  Air  Patrol  (distance)  -  3  hrs  (100  nm) 
Outriggers  -  2 

Max  Vertical  T-O  Wt  - 18,950  lbs. 

Max  Vertical  Landing  Wt  - 18,650  lbs. 

Hi-Lo-Hi  Range  -  480  nm 

Maverick -yes 

Sidewinder  -  yes 

Mk  Series  Bombs  -  yes 

Mk  Series  LGB  -  yes 

Bullpup  -  yes 

HARM  -  yes 

Rockeye-yes(4) 

CBU-59  -  yes 
GATOR  mines  -  yes 
Hellfire  -  yes 


TAV-8A 


TAV-8B 


Figure  B-3.10.  AV-8  class  attributes  and  AV-8B  object. 
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Step 

Physical 

Agent 

Event 

C2 

Enemy  contact 

Hilltop 

Valley  (threat) 

T64  tank  (tracked 
vehicle) 

U.S.  Airborne  Infantry  Company 
Enemy  Tank  platoon 

Co  Cdr 

Daylight 

Defend  (mission) 

SOP 

ROE 

Plan 

Attack  (mission) 

Company 
Commander 
informs  Bn  S3 

Radio  A 

U.S.  Airborne  Infantry  Company 
U.S.  Abn  Inf  Bn 

Commander 

S3 

CoA  (reporting) 

Situation  report 
(SITREP) 

COA  (asking  for  help) 

S3  tasks  FAC 
to  request 
immediate 

CAS 

Radio  A 

Bn  TOC 

Jeep 

S3 

FAC 

Bn  Cdr 

U.S.  Abn  Inf  Bn 

U.S.  AF  Combat  Reporting 

Center  (CRC) 

Order 

SOP 

Task  Statement 

FAC  formu¬ 
lates,  issues 
immediate  air 
request 

Map  and  overlay 
Radio  B 

FAC 

U.S.  Abn  Inf  Bn 

Bde  TACP 

U.S.  Abn  Inf  Bde 

COA 

OPORD 

SOP 

Immediate  air  request 
message 

Bde  TACP 
checks 
resources, 
coordinates 
w/Bde  S3,  for¬ 
wards  request 
to  Div 

Radio  B 

Map  and  overlay 

Bde  TACP 

U.S.  Abn  Inf  Bde 

Div  TACP 

U.S.  Abn  Inf  Div 

Bde  S3 

Bde  Cdr 

OPORD 

SOP 

Immediate  air 
request  message 

Figure  B-4a.  Object  definition. 


step 

Physical 

Agent 

Event 

C2 

Div  TACP  checks 
resources,  coordi¬ 
nates  w/Div  G3,  for¬ 
wards  request  to 

Corp 

Radio  B 

Map  and  overlay 

Div  TACP 

U.S.  Abn  Inf  Div 

BCE 

U.S.  XVIll  Abn  Corps 

Div  G3/air 

ATO 

SOP 

Immediate  air  request 
message 

OPORD 

BCE  tasks  AV-8Bs 

Radio  B 

AV-8B 

Corps  Main  CP 

Loiter  area 

CP 

BCE 

Flight  Cdr 

Wingman 

Marine  Attack  Sqdn 

Move 

Order 

Mission  Stmt 

Control  point 

CEOI 

FAC  relocates  to  Co 
Cdr 

Jeep 

Map  and  overlay 

GPS 

Road 

FAC 

U.S.  Abn  Inf  Bn 

U.S.  Abn  Inf  Co 

Co  Cdr 

Move 

FAC  formulas  air 
mission  order 

U.S.  Abn  Inf  Co  CP 

Map  and  overlay 

IP 

FAC 

U.S.  Abn  Inf  Bn 

SOP 

Order 

AV-8Bs  reach  CP, 
establish  voice 
comm 

Radio  B 

Flight  leader 

Wingman 

FAC 

U.S.  Abn  Inf  Bn 

Marine  Attack  Sqdn 

SOP 

Order 

Figure  B-4b.  Object  definition. 
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Step 

Physical 

Agent 

Event 

C2 

FAC  issues 

CAS  mission 

Radio  B 

IP 

RP 

Route 

AV-8B 

Map  and  overlay 

Flight  leader 

Wingman 

FAC 

U.S.  Abn  Inf  Bn 

Marine  Attack  Sqdn 

Mission  statement 
Order 

ROE 

AV-8BS  per¬ 
form  mission 

IP 

RP 

Route 

Radio  B 

T64 

Valley 

Smoke 

AV-8B 

ROCKEYE 

Hill 

Map  and  overlay 

Flight  leader 

Wingman 

Marine  Attack  Sqdn 

Enemy  Tank  platoon 

U.S.  Abn  Inf  Co 

Air-ground 

engagement 

Report 

SOP 

COA 

ROE 

Figure  B-4c.  Object  definition. 


step 

Physical 

Agent 

Event 

C2 

FAC  evalutes  and 
reports  BDA 

Radio  B 

Map  and  overlay 

Binoculars 

T64 

Valley 

Hill 

Smoke 

FAC 

U.S.  Abn  Inf  Bn 

Flight  leader 

Wingman 

Marine  Attack  Sqdn 

U.S.  Abn  Inf  Co  Cdr 

U.S.  Abn  Inf  Bn  S3 

SOP 

Report  (SITREP) 

CEOI 

Planes  go  home 

AV-8B 

Runway 

Air  base 

Route 

Radio  B 

Flight  leader 

Wingman 

Marine  Attack  Sqdn 

BCE 

Marine  DASC 

Marine  MASS 

Marine  TAOC 

Marine  MACS 

Move 

SOP 

CEOI 

Report  (INFLTREP) 

Figure  B-4d.  Object  definition. 


APPENDIX  C: 
SAMPLE  OBJECT  TANK 


c-o 


Land  Vehicle  -  Fighting 

Type_Configuration 

MissionArea 

Type_WpnsSystem_Main 

Purpose_WpnsSystem_Main 

MaxElevation_WpnsSystem_Main 

MinDepression_WpnsSystem__Main 

Traverse_WpnsSystem_Main 

PositionOnVehicle_WpnsSystem_Main 

TypeAmmunition_WpnsSystem_Main 

APFSDS 

HEAT~FS 

HED-T 

HE-FRAG 

Smoke 

QtyAmmunition_WpnsSystem_Main 

Type_WpnsSystem_Secondary 

Purpose_WpnsSystem„Secondary 

MaxElevation_WpnsSysteni_Secondary 

MinDepression_WnpsSystem_Secondary 

Traverse_WpnsSystem_Secondary 

PositionOnVehicle_WpnsSystem__Secondary 

TypeAmmunition_WpnsSystem_Secondary 

QtyAmmunition_WpnsSystem_Secondary 

Type_WpnsSystem_Tertiary 

Purpose_WpnsSystem_Tertiary 

Max_Elev_WpnsSystem_Tertiary 

Min_Depression_WpnsSystem_Tertiary 

Traverse_WpnsSystem_Tertiary 

PositionOnVehicle_WpnsSystem_Tertiary 

Type„Ammunition_WpnsSystem_Tertiary 

Qty_Ammunition_WpnsSystem_Tertiary 

SmokeLaying 

Thickness_Armor_FrontUpper 

Thickness_Armor_FrontLower 

Thickness_Armor_SideUpper 

Thickness_Armor_SideLower 

Thickness_Armor_RearUpper 

Thickness_Armor_RearLower 

Thickness_Armor_TopTurret 

Thickness_Armor_TopHull 

Thickness_Armor_BeilyFront 

Thickness_Annor_BellyRear 

Thickness_Armor_TurretFront 

Thickness_Armor_TuiTetSide 

Type_CollectiveNBCProtectionSystem 

FireControlSystem 


FireSuppressionSystem 

FireControlSystemController 


Tank 

Glacis_Front_Upper 

Type.Hull 

Glacis_Front_Lower 

Location_MainGun_AmmoStowage 

Glacis_Side_Upper 

Type_Loader 

Glacis_Side_Lower 

Glacis_Rear_Upper 

Glacis_Rear_Lower 

Land  Vehicle 

Identity 

Weight_Combat 

Country_Origin 

GroundPressure 

Country  _Operation 

Max„Roadspeed 

Make 

Max_CrossCountrySpeed 

Model 

Max_FordingDepth_Prepared 

LIN# 

Max_FordingDepth_Unprepared 

Year_Manufacture 

Type_FordingEquipment 

Status 

Max_VerticIeObstacleHeight 

Location 

Max_WidthTrench 

Destination 

Engine_Type 

Range_Average 

Engine_Location 

Range_Extended 

Engine_NumberCylinders 

Speed 

Engine_Horsepower 

Direction 

Ratio_HorsepowerTo  Weight 

Type^Armor 

Transmission_Type 

Location_Armor 

Steering_Type 

Thickness_Armor 

Suspension_Type 

ArmamenCType 

Navigation_Type 

MobilitySystem_Type 

VisionSystem^Type 

Axles_Number 

Radius_Turning 

Axles_Location 

Acceleration__0~60 

Wheels_Number 

Acceleration^Qtrmile 

Wheels_Location 

Amphibious 

Bogiewheels^Number 

AmphibiousDrive_Type 

BogiewheeIs_Location 

Electrical_System 

Trailingwheels_^Number 

Communications_System 

Trailingwheels_Location 

MobiiityGear_Spare 

Guidewheels__Number 

Toolkit 

Guidewheels_Location 

MaxPercent_Slope 

Drivewheels_Number 

MaxPercent__Gradient 

Drivewheels_Location 

Associated_PrimeMover 

Articulated_Vehicle 

Associated_Trailer 

Crew_Type 

Guidance_RemoteControlled 

Crew_Number 

Associated_Photo 

Fuel_Type 

Associated_OperatingManual 

FueLCapacity 

Associated_MaintenanceManual 

Body_Length 

Associated_TacticalManual 

Body  Weight 

CollectiveNBCSys 

Body_Width_.Skirts 

Vismod_Type 

Body_Height 

SmokeSystem_Type 

GroundClearance 

IFF_Type 

Tires  Width 

CamouflageSchema_Type 

Track^Width 

CenterOfGravity^Empty 

Track_LengthOnGround 

CenterOfGravity_Loaded 

Weight_UnIoaded 

Color 
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VIRTUAL  FUNCTION  PSEUDOCODE  AND  SAMPLE  IDL 

Pseudocode  and  IDL  are  shown  for  the  Tank  class.  The  Tank  pseudocode  shows  how  different 
degrees  of  resolution  can  be  supported  by  polymorphism  (see  Tank:  Initialize).  It  also  demonstrates 
how  a  good  deal  of  JWSOL  object  content  can  be  abstracted  away  from  simulation  engine  specifics 
(see  Tank:  Move).  (Simulation  engine  is  a  generic  term  referring  to  the  computational  infrastructure 
and  specific  implementation  choices  that  instantiate  a  model  or  simulation.  Normally,  “simulation 
engine”  is  used  to  distinguish  computational  elements  from  the  simulation  content,  i.e.,  the  model  of 
real-world  phenomena.)  Minimizing  simulation  engine  dependencies  is  important  for  a  general-pur¬ 
pose  object  repository. 

There  are  five  virtual  functions  below:  Initialize,  Assign,  Move,  Fire,  and  ReceiveFire. 

Tank:  Initialize 

Create  a  tank  object  and  set  up  its  initial  state 

Create  Tank  object 
Case  Resolution 
“Coarse" 

(initialize  a  subset  of  the  attributes  from  the  “Fine”  resolution 
below) 

“Medium” 

(as  w/ Coarse) 

“Fine” 

Location 

Identity 

Country jOrigin 

CountryjOperation 

Make 

Model 

Lim 

Year_Manufacture 

Status 

Destination 

Range_Average 

Range JExtended 

Speed 

Direction 

Type_Armor 

Location_Armor 

Thickness_Armor 

ArmamentJType 

Type_Armor 

Location_Armor 

Thickness _Armor 

ArmamentJType 
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Mobility _System_Type 

AxlesJLocation 

Wheels_Number 

Wheels JLocation 

Bogiewheels_Number 

Bogiewheels  JLocation 

Trailingwheels_Number 

Trailingwheels_Location 

Guidewheels_Number 

Guidewheels  JLocation 

Drivewheels_Number 

Drivewheels_Location 

Articulated_Vehicle 

CrewJType 

Crew_Number 

FuelJType 

FueljCapacity 

Body_Length 

Body_Weight 

Body_Width_Skirts 

Body_Height 

GroundClearance 

Tires JWidth 

Track_Width 

TrackJLengthOnGround 

Weight_Unloaded 

WeightjCombat 

GroundPressure 

Max_RoadSpeed 

MaxjCrossCountrySpeed 

Max_FordingDepth_Prepared 

Max_FordingDepthJUnprepared 

Type_FordingEquipment 

Max_VehicleObstacleHeight 

Engine  _NumberCylinders 

Engine  JHorsepower 

Ratio JtlorsepowerToWeight 

TransmissionJType 

SteeringJType 

Suspension JType 

Navigation JType 

VisionSystemJType  . 

Radius  JTurning 


Acceleration_0-60 

AccelerationjQtmile 

Amphibious 

AmphibiousDrive_Type 

Electrical_System 

Communications _Sy stem 

MobilityGear_Spare 

Toolkit 

MaxPercentjSlope 

MaxPercentjGradient 

Associated_PrimeMover 

Associated_Trailer 

Guidance_RemoteControlled 

Associated_Photo 

Associated_OperatingManual 

Associated_MaintenanceManual 

AssociatedJTacticalManual 

CollectiveNBCSys 

Vismod_Type 

SmokeSystemJType 

IFFJType 

CamouflageSchemaJType 
Center  OfGravity_Empty 
CenterOfGravityJLoaded 
Color 

TypejConfiguration 
MissionArea 
Type_WpnsSystem_Main 
Purpose_WpnsSystem_Main 
MaxElevation_WpnsSystem_Main 
MinDepression_WpnsSystem_Main 
Max_WidthTrench 
Engine_Type 
Engine  _Location 
Traverse JWpnsSystem_Main 
PositionOnVehicle_WpnsSystem_Main 
TypeAmmunition_WpnsSystem_Main 
APFSDS 
HEAT-FS 
HED-T 
HE-FRAG 

QtyAmmunition_WpnsSystem_Main 

Type_WpnsSystem_Secondary 
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Purpose_WpnsSystem_Secondary 

MaxElevation_WpnsSystem_Secondary 

MinDepression_WpnsSystem_Secondary 

Traverse_WpnsSystem_Secondary 

PositionOnVehicle_WpnsSystem_Secondary 

TypeAmmunition_WpnsSystem_Secondary 

QtyAmmunition_WpnsSystem_Secondary 

Type_WpnsSystem_Tertiary 

Purpose_WpnsSystem_Tertiary 

MaxElevation_WpnsSystem_Tertiary 

MinDepression_WpnsSystem_Tertiary 

Traverse_WpnsSystem_Tertiary 

PositionOnVehicle_WpnsSyslem_Tertiary 

TypeAmmunition_WpnsSystem_Tertiary 

Qty Ammunition JWpnsSystem_Tertiary 

SmokeLayering 

Thickness_Armor_FrontUpper 

Thickness_ArmorjFrontLower 

Thickness_Armor_Side  Upper 

Thickness_Armor_SideLower 

Thickness_Armor_RearUpper 

Thickness_Armor_RearLower 

Thickness_Armor_TopTurret 

Thickness_A  rmorJTopHull 

Thickness_Armor_BellyFront 

Thickness_Armor_Bellyrear 

Thickness_Armor_TurretFront 

Thickness _Armor_TurretSide 

TypejCollectiveNBCProtectionSystem 

FireControlSystem 

FireSuppressionSystem 

FireControlSystemController 

Glacis _Front_Upper 

Glacis_Front_Lower 

Glacis _Side_Upper 

Glacis_Side_Lower 

Glacis _Rear_Upper 

Glacis  _Rear_Lower 

TypeJBull 

Location_MainGun_AmmoStorage 
Type_Loader _ 

End  Tank:  Initialize 
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End  Tank:  Fire 
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Tank:  Move 


Move  from  one  Location  to  another 

If  Status  (self)  is  not  “Operational”  Or  “Mobile" 

Send  owner  Org.  “Update  Status  (self  ID)”  msg. 

Send  Move  “Purge  all  ‘Arrive  Time/Location  ‘  msg.  ’s  for  ( self  ID)  ” 

Else 

Set  Destination  to  input  Location 

If  Location  ( self)  is  same  as  Destination 

Send  owner  Org.  “Arrived  (self  ID,  Location)”  msg. 

Else 

Plot  route  vis-a-vis  simulation  spatial  representation 
If  POL  (Le.yfuel)  is  not  adequate 

Report  problem  to  owner  Org. 

Else 

If  Resolution  is  “Coarse” 

Send  Move  obj.  “Arrive  (self  ID)  Time/Location”  msg. 

Else  (Resolution  is  “Medium”  or  “Fine”) 

Build  movement  conditions  profile 

Query  Precipitation  objects  on  route 
Query  SurfacejCover  objects  on  route 
If  SurfacejCover  is  impassable 
And  (no  mediation,  e.g..  Bridges  over  River) 
Report  problem  to  owner  Org.  &  Exit 
Query  Obstacle  objects  on  route 
If  Obstacle  is  impassable 

Report  problem  to  owner  Org.  &  Exit 
Query  Env.JPhenom.  objects  on  route 
IfEnv.  is  impassable  (e.g.,  flood,  hurricane,  etc.) 
Report  problem  to  owner  Org.  &  Exit 
Build  topographical  profile 

Query  Topography  objects  on  route 
Add  increment  to  topographical  profile 
If  Topography  is  impassable 

Report  problem  to  owner  Org.  &  Exit 
Calculate  movement  time:  point-to-point  on  route 

Send  Move  (event  object)  series  of  “Arrive  (self  ID) 

Time/Location  (self)”  messages 
End  Tank:  Move 
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Tank:  Receive  Fire _ 

Receives  fire  (default  is  from  OPFOR,  although  could  be  specialized  to  also  receive  fire  from  friend¬ 
lies  if  a  simulation  needed  to  model  such  events). 


If  Status  (self)  is  “Operational” 

Translate  incoming  fire  to  resolution-independent  form 
Assesses  self-damage: 

Case  Kind  of  fire 

Rockeye  Set  Status  (self)  =  “Destroyed” 

MlAl  Cannon  Set  Status  (self)  =  “Destroyed” 

etc. 


(self) 


End  case 

Send  own  “Assigned-To”  Military jOrganization  object  “Update  Status”  msg.,  with  ID 

End  Tank:  Receive  Fire 


More  detail  could  be  developed  for  the  virtual  function  pseudocode  above  if  a  particular  modeling 
need  called  for  it.  For  example,  in  Tank:  Move,  calculation  of  movement  through  obstacles  could  use 
Body_Length,  Body_Height,  Body_Width,  Weight_Combat,  Track_LengthOnGround,  Max_Verti- 
cal-ObstacleHeight,  Max_WidthTrench,  etc.  Similarly,  Tank:  ReceiveFire  could  use  details  on 
armor,  location  of  hit,  specific  munition,  etc.,  to  determine  degree  of  damage. 


The  Tank  Interface  Definition  Language  (IDL)  specification  follows. 


If  ************************************************************ 

// 

//  Tank  interface  specification  (sample) 

// 

II  ************************************************************ 
f f  ************************************************************ 

typedef  string  Resolution; //  "Coarse",  "Medium",  "Fine" 

typedef  long  Coordinate;//  x,  y,  &  poss .  z 
typedef  sequence  <Coordinate>  Location; 

interface  Tank  { 

exception  Tank_Invalid__Init(); 
exception  Tank_Invalid_Assignment ( ) ; 
exception  Tank_Invalid_StatusRequest ( ) ; 
exception  Tank_Invalid_Mission ( ) ; 

//  Tank:  Initialize 

//  Receives  Resolution,  Location,  and  poss.  the  AgentID 
//  for  the  Mil,_Org.  to  which  it  is  assigned 
//  Provides  own  ID,  Status  to  owner  Mil,_Org.if  possible 
void  Tank_Initialize  ( 

in  string  Resolution, 

in  Location  CurrrentLocation, 

in  AgentID  Assigned_To,  / /  If  the  AgentID  is  not  of 

//  correct  type,  raise 
//  exception 

out  FightVehiclelD  self  ID,  //  Send  if  AgentID  in  call 
out  string  Status  //  Send  if  AgentID  in  call 

) 

raises  (Tank_Invalid_Init ) ; 
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//  Receives  Resolution,  requestor  ID 

//  Provides  Status,  Location,  and  (according  to 
//  Resolution)  many,  many  other  attribute  values 
void  Tank_Status  ( 


in 

string 

Resolution, 

in 

AgentID 

Requestor,  //If  AgentID  is  not  valid 

//  requestor,  raise  exception 

in 

string 

attributeSpecif ier ,  //  if  null, 

//  Status  only 

selfID  and 

out 

FightVehiclelD  selfID, 

out 

string 

Status , 

out 

AtrToken 

attributeValue  //  content  will 
//  vary  according 

to  input 

//  AttributeSpecif ier 

) 

rais es  ( Tank_Inva 1 id_S tatusReques  t } ; 


//  Receives  the  AgentID  for  the  Mil._Org.  to  which  it  is 
//  assigned,  or  Engagement  type  (Gnd_Gnd, Gnd_Air , 

//  Gnd_Surface,  Gnd_Space, Air_Gnd, Surf_Gnd,  Subsurf_Gnd) 

//  Provides  own  ID,  Status  to  owner  Mil._Org.if  possible 
void  Tank_Assign  ( 

in  AgentID  Assigned_To,  //  If  bad  AgentID,  raise 

//  exception 

in  EventID  Engaged,  //  If  bad  EventID,  raise 

//  exception 

out  FightVehiclelD  selfID,  //  return  selfID  and  Status 
out  string  Status,  //  if  Agent  assignment 

) 

raises  (Tank_.Invalid_Assignment )  ; 

//  Receives  Resolution,  destination  Location,  AgentID  for 
//  Mil._Org.  to  which  it  is  assigned. 

//  Provides  Location_@_Time,  Status 
void  Tank_Move  ( 


in 

string 

Resolution, 

in 

Location 

Destination, 

in 

AgentID 

CommandSource , 

//  If  CmndSource  not  same 
//  as  Assigned_To  or  superior 
//  to,  raise  exception 

out 

FightVehiclelD  selfID, 

out 

string 

Status , 

out 

short 

Time, 

out 

Location 

CurrrentLocation  // 

) 

raises  (Tank_Invalid__Assignment )  ; 
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//  Receives  Resolution,  OPFOR  target  ID,  and  OPFOR  Location 
//  Provides  W^aponType,  and  "Fire"  or  "Fire  from"  plus 
//  munitions  ID  to  target 
void  Tank_Fire  ( 

in  string  Resolution, 

in  AgentID  CommandSource,  //  If  CmndSource  not  same 

//as  Assigned_To  or  superior 
//  to,  raise  "Assign"  excptn 
in  AgentID  Target_Agent ,  //  Only  one  of  Agent  and 

in  PhysicallD  Target_Physical , / /  Phys ,  will  be  non-null 

//  If  Target  is  not  valid 
//  type  re:  MissionArea., 

//  raise  "Mission"  excptn 

in  Location  Target_Location, 

out  string  Type_WpnsSystem, / /  "Main",  "Secondary",  or 

//  "Tertiary",  as  app. 

out  string  Type„Munition  //  Sent  if  Res.  =  med  or  fine 

) 

raises  (Tank_Invalid_Assignment ,  Tank_Invalid_Mission)  ; 

//  Receives  WeaponType,  and  either  "Fire"  or  "Fire  from" 

//  plus  munitions  ID 

//  Provides  Status  to  he  Mil._Org.  to  which  it  is 
//  assigned,  also  poss.  to  its  curent  Engagement  object 
void  Tank„ReceiveFire  { 

in  string  Resolution, 

in  string  Type_Wpns System,  //  Phys.  will  be  non-null 

in  string  Type_Munition  //  If  Res.  =  med  or  fine 

out  FightVehiclelD  selfID,  • 
out  string  Status 

)  ; 
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Figure  D-1 .  State  diagram  for  the  mission  of  Forward  Air  Controller  (Airborne)  FAC(A). 
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IFF/SIF 


Note:  Ingress/Egress/Return  to  Force  (RTF)  procedures  must  be 
followed  In  exacting  detail.  Any  and/or  all  listed  must  be  followed  to 
avoid  fratricide  and  maximize  the  safety  of  the  defended  area. 

Figure  D-2.  Data  flow  diagram  for  Safe  Passage  state. 
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Note:  Command  and  control  agency  names  vary  depending  on 
combined,  unified,  and/or  service  doctrine.  They  may  include  air 
control,  air  defense,  and  air  support  agencies. 

Figure  D-3.  Data  flow  diagram  for  Enroute  Coordination  state. 
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Note:  Aggregate  of  the  data  stores  to  locate  target  or  target  area 
FAC  will  describe  the  cues  that  will  eventually  focus  the  pilot’s 
attention  on  the  target,  or  the  immediate  target  area.  For 
example,  he  may  start  with  2  kilometers  north  of  x  and  y  road 
intersection,  followed  by  100  meters  west  of  the  white  church. 

Figure  D-4.  Data  flow  diagram  for  Locate  Target  state. 


Threat 

Database 


Note:  Prior  to  entering  the  target  area,  it  is  important  to  know  if 
there  are  threats  that  could  shoot  you  and/or  supporting  aircraft 
down.  The  Threat  Database  will  provide  detailed  and  accurate 
information  on  fixed  sites.  On-board  sensors  are  used  to 
determine  if  these  fixed  sites  are  active  and  is  the  first  indicator 
of  mobile  systems. 

Figure  D-5.  Data  flow  diagram  for  ID  Threat  Systems  state. 


Note:  Target  Database  can  provide  precise  locating  information, 
but  more  normally,  the  unit  requesting  the  CAS  will  provide 
precise  target  ID. 

Figure  D-6.  Data  flow  diagram  for  ID  Target  state. 
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FAC 

FAC(A) 


Note:  Any,  and/or  all  of  the  action/data  stores  could 
be  used  to  find/confirm  where  the  requesting  unit  is 
actually  located. 

Figure  D-7.  Data  flow  diagram  for  Locate  Requesting  Unit  state. 
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could  hit  the  aircraft  must  be  suspended. 
The  FAC  must  also  ensure  that  he  knows 
where  these  units  are  located  to  avoid 
friendly  fire  casualties. 

Figure  D-8.  Data  flow  diagram  for  Coordinate  with  Adjacent  Forces  state. 
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available  weapon  and  the  numbers  of  each  kind  required  to 
destroy/damage  the  target.  Requesting  unit  notifies  the  FAC 
how  close  he  is  to  the  target.  For  example,  the  best 
ordnance  to  destroy  the  target  may  have  a  damage  radius 
that  would  pose  a  (serious)  danger  for  friendly  forces.  In 
such  a  case,  another  kind  of  ordnance  may  be  chosen 
unless  the  threat  warrants  the  danger  to  friendlies. 

Figure  D-9.  Data  flow  diagram  for  Determine  Optimum  Ordnance  state. 
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Beacon 


Note:  It  is  not  appropriate  to  discuss  the  factors  that  weight 
the  decision.  Important  are  the  trade-offs  in  accuracy 
(lethality)  and  survivability.  Tables  are  available  that  compare 
these  factors. 


Figure  D-10.  Data  flow  diagram  for  Determine  Attack  Profile  state. 
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Note:  The  FAC  queries  the  data  stores  described  to 
determine:  (1)  the  best  delivery  system;  (2)  can  the 
best  system  carry  and  deliver  the  optimum  ordnance 
and  fly  the  profile  dictated  by  the  threat. 

Figure  D-11.  Data  flow  diagram  for  Determine  Optimum  Delivery  Platform  state. 
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Optimum 

Delivery 

Platform  Note:  FAC(A)  checks  the  ATO  and  DASC  for  availability  of  the 

preferred  platform  and  ordnance  and  makes  a  selection  from  the 
assets  available  that  can  best  perform  the  mission. 

Figure  D-12.  Data  flow  diagram  for  Select  Delivery  Platform  state. 
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Note:  FAC  (or  FAC(A))  will  formulate  a  “FAC  Briefing  Card” 
that  includes  these  (and  in  the  case  of  Beacon  Bombing 
other)  data.  JCS  publication  12,  Vol.  II  has  detailed  info  on 
Joint  Tactical  Air  Strike  Request. 

Figure  D-13.  Data  flow  diagram  for  Brief  Pilots  state. 
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Note:  The  most  basic,  but  most  critical  task,  a  pilot  does  is  fly  the  aircraft, 
i.e.,  “Air  Navigate.”  If  he  does  it  wrong  through  a  lack  of  training  or 
experience  or  improperly  through  a  lack  of  attention,  the  mission  will  not 
succeed. 

Figure  D-14.  Data  flow  diagram  for  Air  Navigate  state. 


Note:  When  the  pilot  is  in  the  immediate  vicinity  of  the  target,  he 
may  (or  more  likely  may  not)  see  the  actual  target.  At  that  time,  the 
FAC  will  mark  the  target  in  some  manner  (white  smoke)  to  make 
sure  the  pilot  drops  his  ordnance  in  the  right  place. 

Figure  D-15.  Data  flow  diagram  for  Mark  Target  state. 
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Note:  If  the  pilot  sees  the  mark,  acknowledges  correction  from  the  mark, 
and  the  FAC(A)  sees  the  pilot,  he  is  cleared  to  make  his  target  run. 

Figure  D-16.  Data  flow  diagram  for  Clear  for  Attack  state. 


Note:  The  final  control  measure,  to  ensure  the  pilot  has  acquired 
the  right  target  and  won’t  release  his  ordnance  on  friendiies,  is  to 
visually  make  sure  the  pilot  is  pointing  at  the  target;  at  that  time  he 
is  cleared  for  ordnance  release.  If  he  does  not  receive  this 
clearance,  he  must  not  release  the  ordnance. 

Figure  D-17.  Data  flow  diagram  for  Clear  for  Weapons  Release  state. 
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Note:  The  FAC(A)  observes  where  the  ordnance  has  impacted 
and  tells  the  pilot  to  change  his  aimpoint  to  directly  impact  the 
target.  This  procedure  is  repeated  on  subsequent  “runs”  until  the 
target  is  destroyed  or  the  pilot  has  exhausted  his  ordnance  supply. 

Figure  D-18.  Data  flow  diagram  for  FAC  Adjust  Aimpoint  state. 
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Unit  Note:  Attacks  are  terminated  (aborted)  for  safety  reasons  if  the 

Commander  FAC(A)  and/or  unit  commander  believe  the  pilot  is  conducting  the 

attack  in  an  unsafe  manner  that  endangers  him  or  the  friendly  forces 
on  the  ground. 

Figure  D-19.  Data  flow  diagram  for  Abort  Attacks  state. 
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Note:  Reattacks  are  performed  under  positive  control  and  in  the 
same  manner  as  before. 

Figure  D-20.  Data  flow  diagram  for  Control  Reattacks  state. 
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Figure  D-21 .  Data  flow  diagram  for  Cancel  Mission  state. 
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Figure  D-23.  State  diagram  for  the  mission  of  Forward  Air  Controller  (FAC). 
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Figure  D-25.  Data  flow  diagram  for  Land  Navigate  state. 
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Figure  D-26.  State  diagram  for  the  mission  of  Close  Air  Support  (CAS). 
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Note:  FAC  or  FAC(A)  provides  details  of  how  the  mission  will 
be  conducted.  Pilot  repeats  all  instructions  and  must  not 
deviate  unless  approved  by  FAC/FAC(A). 

Figure  D-27.  Data  flow  diagram  for  close  air  support  FAC  Briefing  state. 
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Note:  Aggregate  of  the  data  stores  and,  in  particular,  FAC/FAC(A) 
directs  pilot  to  the  target  or  target  area. 

Figure  D-29.  Data  flow  diagram  for  close  air  support  Locate  Target  state. 


Note:  FAC  or  FAC{A)  marks  the  target  and  provides  correction 
information.  Piiot  sees  the  mark  and  acknowledges  where  to 
correct  from  the  mark. 

Figure  D-30.  Data  fiow  diagram  for  close  air  support  Observe  Target  Mark  state. 


Note:  FAC  or  FAC(A)  observes  the  aircraft  has  apparently 
acquired  the  target  and  dears  the  pilot  to  commence  the  attack. 

Figure  D-31 .  Data  flow  diagram  for  close  air  support  Commence  Attack  state. 
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Note:  When  the  pilot  is  established  in  the  flight  path  and  pointed  at 
the  target,  he  is  cleared  to  release  weapons.  Pilot  releases  weapons 
if  he  is  sure  he  has  target  and  the  flight  path  is  an  accceptable  one. 

Figure  D-32.  Data  flow  diagram  for  close  air  support  Release  Weapons  state. 


Note:  FAC  or  FAC(A)  provides  correction  information  from  target 
mark.  Pilot  applies  the  correction  information,  adjusts  the  flight  path, 
and  acknowledges  FAC/FAC(A)  correction  information  from  the 
mark. 

Figure  D-33.  Data  flow  diagram  for  close  air  support  Adjust  Aimpoint  state. 
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Figure  D-34.  State  diagram  for  the  mission  of  offensive  counterair  operations. 
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Figure  D-35.  State  diagram  for  the  engagement  of  offensive  counterair  operations. 
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Note:  The  pilot  must  know  and  update  his  knowledge  of  the  most  important 
air  defense  priorities  (i.e.,  which  enemy  assets  are  the  most  critical,  which 
are  the  most  vulnerable,  recovery  time  from  inflicted  damage,  and  those 
enemy  assets  most  vulnerable).  He  must  also  know  and  recognize  the  Air 
Defense  Operations  Area  and  the  specific  Air  Defense  Area  and  Region  he 
is  scheduled  to  operate  within. 

Figure  D-36.  Data  flow  diagram  for  offensive  counterair  operations  Air  Defense 
Control  Measures  state. 
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Note:  Prior  to  proceeding  with  the  mission  the  pilot  must  confirm 
that  the  described  systems  required  for  the  mission  are  operating 
properly  (i.e.,  if  AEW/C  —  Airborne  Early  Warning  and  Control 
aircraft  (E-2C/E-3C)  are  required  for  the  mission  they  must  be 
operating). 

Figure  D-37.  Data  flow  diagram  for  offensive  counterair  operations  Check  Weapons  Status. 
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Note:  Under  “weapons  free”  criteria,  it  is  assumed  anything  found  on 
radar  or  visually  is  an  enemy.  The  pilot  is  clear  to  engage.  Under 
“weapons  tighf  criteria,  engagement  is  permitted  only  when  cleared 
or  when  the  ROE  has  been  met. 

Figure  D-39.  Data  flow  diagram  for  offensive  counterair  (fighter  sweep)  Control 
Procedures  state. 
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Note:  These  criteria  ensure  that  the  most  serious  threat  will  be 
engaged  first,  i.e.,  MIG-31  before  MIG-17.  ROE  criteria  must  still  be 
met,  friendly  forces  avoided  and,  critically,  the  threat  aircraft  must  be 
within  the  engagement  envelope  for  the  weapon  selected. 

Figure  D-40.  Data  flow  diagram  for  offensive  counterair  (fighter  sweep)  Engagement 
Criteria  state. 
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Note:  Altitudes  are  chosen  to  cover  radar  gaps;  speed  depends  on 
enemy  threat  and  time  on  station  requirements.  Search  patterns 
cover  radar  gaps  and  threat  tactics.  Formations  come  from 
classified  tactical  manuals.  ROE  should  allow  pilots  to  use  offensive 
tactics.  Commit  criteria  means  how  and  under  what  conditions 
attacks  are  initiated. 

Figure  D-41 .  Data  flow  diagram  for  offensive  counterair  (CAP)  Employment  Factors 
state. 
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Note:  Identify,  prioritize,  and  locate  enemy  threats.  Determine  where 
escort  aircraft  will  be  in  reiation  to  attack  package  and  what  tactical 
formation  they  will  fly.  Ensure  all  know  ROE.  Specify  time  on  target 
for  primary/secondary  targets.  Ensure  all  know  code  words  for  each 
primary  evolution  (TOT  change,  target  change,  threat  attack,  etc.). 

Figure  D-42.  Data  flow  diagram  for  offensive  counterair  (strike  operations)  Escort 
Coordination  stage. 
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Note:  SEAD  is  applied  at  only  critical  times  to  allow  air  forces  to 
accomplish  their  mission  without  prohibitive  interference  from  the 
enemy  air  defenses. 

Figure  D-43.  Data  flow  diagram  for  offensive  counterair  (strike)  SEAD  state. 


D-38 


Fighter 

Engagement 

Zone 


Weapons 

Tight 


Note;  Under  “weapons  free”  criteria,  it  is  assumed  anything  found  on 
radar  or  visually  is  an  enemy.  The  pilot  Is  clear  to  engage.  Under 
“weapons  tight”  criteria  engagement  is  permitted  only  when  cleared 
or  when  the  ROE  has  been  met.  Engagement  is  authorized  within 
assigned  Fighter  Engagement  Zone  (FEZ)  only. 

Figure  D-44.  Data  flow  diagram  for  offensive  counterair  (CAP)  Control 
Procedures  state. 
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Note:  These  criteria  ensure  that  the  most  serious  threat  will  be 
engaged  first,  i.e.,  MIG-31  before  MIG-17.  Roe  criteria  must  still  be 
met,  friendly  forces  avoided  and,  critically,  the  threat  aircraft  must  be 
within  the  engagement  envelope  for  the  weapon  selected. 

Figure  D-45.  Data  flow  diagram  for  offensive  counterair  (CAP)  Engagement  Criteria 
state. 
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Note:  Attack/reattack  criteria  are  determined  by 
target  value  and  threat  systems  protecting  the 
target.  Attack/reattack  procedures  must  be  well 
understood  by  all  participants. 


Figure  D-46.  Data  flow  diagram  for  offensive  counterair  Attack/Reattack  state. 


Note:  The  Air  Defense  Commander  cancel  order  and/or  onboard 
weapons  inoperable  are  mandatory  mission  termination  criteria.  All 
other  sub-states  require  a  pilot  judgement  and  depend  on  criticality 
of  the  mission  and  the  level  of  threat  anticipated. 

Figure  D-47.  Data  flow  diagram  for  offensive  counterair  operations  Cancel  Mission  state. 
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Figure  D-48.  State  diagram  for  aircraft  mission. 
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Taxi 


Each  aircraft  has  very  specific  procedures  contained  in  the 
individual  data  stores  for  each  type,  model,  series  aircraft. 

Figure  D-49.  Data  flow  diagram  for  aircraft  Normal  Procedures  state. 
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Note;  Each  aircraft  has  very  specific 
procedures  contained  in  the  individual  data 
stores  for  each  type,  model,  and  series  aircraft. 

Figure  D-50.  Data  flow  diagram  for  aircraft  Emergency  Procedures  state. 
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General 


known  and  recognized,  e.g.,  take-off  speed,  stall 
speed.  Similarly,  each  aircraft  has  specific 
characteristics  that  define  its  capabilities  and  limits, 
e.g.,  vertical  takeoff  and  landing  for  the  AV-8. 

Figure  D-51 .  Data  flow  diagram  for  aircraft  Flight  Characteristics  state. 
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Note:  All  aircraft  have  model-specific  procedures  to 
successfully  fly  in  each  of  the  four  specific  cases  listed. 

Figure  D-52.  Data  flow  diagram  for  aircraft  All  Weather  Operations  state. 
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Equipment  and  procedures  vary  from  model/series,  but  all 
have  at  least  some  level  of  sophistication.  Pilots  set  and 
change  frequencies  and  equipment  to  comply  with 
requirements;  use  equipment  displays  to  navigate  and  locate 
targets,  zones  of  action,  and  in  a  growing  number  of  aircraft, 
videotape  critical  portions  of  the  mission. 

Figure  D-53.  Data  flow  diagram  for  aircraft  Communications  and  Navigation  Procedures  state. 
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Brief 


Note:  Critical  to  mission  accomplishment.  Each  crew  member 
must  understand  and  execute  his  responsibilities  in  each  and 
every  data  state  to  accomplish  the  mission. 

Figure  D-54.  Data  flow  diagram  for  aircraft  Flight  Crew  Coordination  state. 
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Aircraft 


Note:  Individual  aircraft  tactical  manuals  (parts  classified) 
provide  detailed  information. 

Figure  D-55.  Data  flow  diagram  for  aircraft  Performance  Data  state. 


Note:  Weapons  available  vary  by  aircraft.  Specific  tactical 
manuals  list  weapon  carriage  and  delivery  parameters  and  limits. 

Figure  D-56.  Data  flow  diagram  for  aircraft  Weapons  Systems  state. 
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Figure  D-57.  State  diagram  for  the  mission  of  helicopterborne  assault. 
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Note:  Terminal  control  agencies  direct  final  delivery 
of  cargo,  personnel,  and  ordnance.  They  perform 
specialized  tasks  not  handled  by  other  control 
agencies. 


Figure  D-58.  Data  flow  diagram  for  Coordinate  Terminal  Control  state. 
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Note:  Prior  to  commencing  the  assault,  the  pilot  (Air  Mission 
Commander)  must  determine  if  the  preparation  of  the  landing 
zone  has  been  effective.  Additional  preparation  is  normally 
done  through  the  FAC,  FAC(A),  or  DAC(A).  In  their  absence, 
the  pilot  will  call  for  and  adjust  fire  from  artillery/attack 
helicopters  or  CAS  aircraft. 

Figure  D-59.  Data  flow  diagram  for  helicopterborne  assault  Landing  Zone  Preparation  state. 
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Note:  Changing  landing  zones  is  normally  the  responsibility  of  the 
pilot  (Air  Mission  Commander  or  the  helicopter  Unit  Commander.) 
However,  if  the  scheme  of  maneuver  on  the  ground  is  affected,  this 
authority  cannot  be  delegated  below  the  highest  unit  affected. 

Figure  D-60.  Data  flow  diagram  for  helicopterborne  assault  Select  Landing  Zone  state. 
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Air  Support 
Assets 


Note;  The  Pilot  (Air  Mission  Commander)  ensures  the  fixed  and 
rotory  wing  air  support  assets  are  at  their  proper  initial  points,  that 
the  proper  sequence  of  events  is  adhered  to;  if  enemy  actions 
are  adversely  affecting  mission  accomplishment,  he  must  delay  or 
cancel  the  insertion. 

Figure  D-61 .  Data  flow  diagram  for  helicopterborne  assault  Troop  Insertion  state. 


Schedule  of 
Events 


Note:  Under  normal  circumstances,  extractions  will  be  conducted 
after  the  mission  has  been  accomplished  (benign  environment).  In 
that  event  the  extraction  is  nothing  more  than  an  administrative 
movement.  In  the  event  of  enemy  interference,  the  extraction  is 
controlled  like  an  insertion,  i.e.,  assets  sufficient  to  suppress  fire 
and  safely  remove  the  force  are  brought  to  bear  on  the  enemy. 

Figure  D-62.  Data  flow  diagram  for  helicopterborne  assault  Troop  Extraction  state. 
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Figure  D-63.  State  diagram  for  the  mission  of  attack  helicopter  operations. 
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Note:  The  controlling  agency  will  formulate  a  “FAC  Briefing 
Card”  that  includes  these  data. 

Figure  D-64.  Data  flow  diagram  for  attack  helicopter  operations  Target  Brief  state. 
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Figure  D-65.  Data  flow  diagram  for  helicopterborne  assault  Cancel  Mission  state. 
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Note:  The  pilot  (Air  Mission  Commander)  determines  that  the 
mission  has  been  successfully  accomplished  and  relays  his 
judgement  to  the  unit  commander,  who  concurs.  The  pilot  informs 
all  control  agencies  that  the  mission  has  been  accomplished,  where 
the  troops  were  inserted/extracted  from,  and  at  what  time. 


Figure  D-66.  Data  flow  diagram  for  helicopterborne  assault  Mission  Complete  state. 
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Figure  D-67.  State  diagram  for  Execute  Small  Arms  Direct  Fire  engagement. 
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Figure  D-68.  Data  flow  diagram  for  Process  Fire  Command/Engagement  Messages,  Execute  Small 
Arms  Direct  Fire  engagement. 
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*  Target  query  message  asks  target  object  its  identity,  vulnerability  (ordnance  look-up  table)  based 
on  the  object’s  lethality  table  (what  it  can  engage  with).  If  no  match,  engagement  ceases. 

**  Target  query  response  message  confirms  weapons/ordnance  to  which  the  target  is  vulnerable 
(i.e.,  you  can  fire  at  a  tank  with  an  M-2  .50  cal  machine  gun  and  it  will  not  affect  it,  but  a  120  mm 
tank  main  gun  round  will.  Both  are  available  on  a  M1 A2  Abrams  MBT.) 

Figure  D-69.  Data  flow  diagram  for  Prepare  for  Engagement,  Execute  Small  Arms  Direct  Fire 
engagement. 


*  If  elevation  along  GTL  exceeds  LOS  betweenweapon  and  target,  target  is  not  confirmed. 

**  If  range  to  target  exceeds  max  effective  range  of  weapon,  target  is  not  confirmed. 

***  If  azimuth  to  target  exceeds  traverse  of  weapon  system  (+/-)  azimuth  of  direction,  target  is  not  confirmed. 
****  If  range  to  target  exceeds  minimum  visibility  along  GTL,  target  is  not  confirmed. 

Figure  D-70.  Data  flow  diagram  for  Establish  Target  Lock,  Execute  Small  Arms  engagement. 
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Map  Data  File 


*  Intervening  elevation,  excessive  range,  or  low  visibility. 

**  Object  may  be  constrained  in  movement,  or  new  location  may  exceed 
permitted  movement  time,  be  “out  of  area,”  or  be  occupied  by  another  C? 
entity.  . 

Figure  D-71 .  Data  flow  diagram  for  Change  Position,  Execute  Small  Arms  engagement. 
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*  Ordnance  object  is  queried  for  required  elevation  and  time  of  flight  at  given  range  to  target. 
**  Relative  speed  of  target  is  calculated  using  the  actual  speed  factored  by  angle  of 
incidence  to  the  GTL 

Figure  D-73.  Data  flow  diagram  for  Calculate  Small  Arms  Ballistics,  Execute  Small  Arms 
Direct  Fire  engagement. 


D-67 


*  GTL(D)  =  Modified  gun-target-line  to  include  deflection  caused  by  relative 
speed  of  object  and  cross-wind  factors 

Figure  D-74.  Data  flow  diagram  for  Aim  Weapon,  Execute  Small  Arms  Direct  Fire  engagement. 
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*Upon  receipt  of  engagement  message,  weapon  object  activates  entity;  receiving  fire 
resulting  in  a  BDA  message  being  sent  to  the  weapon  C^bject. 

Figure  D-75.  Data  flow  diagram  for  Fire  Weapon,  Execute  Small  Arms  Direct  Fire  engagement. 
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*  GTL:  Gun-Target-Line  can  be  in  degrees  or  mils,  magnetic  or  UTM  grid. 

**  TOT:  Time-on-Target 

Figure  D-76.  State  diagram  for  Execute  Small  Arms  Direct  Fire  engagement. 
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*  Virtually  any  physical  object  can  be  a  target  object  (tree,  bridge,  soldier, 
tank).  Refer  to:  State  Diagram  for  Receiving  Fire. 


Figure  D-77.  Data  flow  diagram  for  Fire  Weapon,  Execute  Small  Arms  Direct  Fire  engagement. 


Weapon 


Figure  D-78.  Data  flow  diagram  for  Aim  Weapon,  Execute  Small  Arms  Direct  Fire  engagement. 
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Figure  D-79.  State  diagram  for  Receiving  Fire  (direct,  indirect,  guided,  observed,  unobserved). 
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*GTL:  Gun-target-line 

**Direction  of  fire  is  merely  back-azimuth  of  GTL 
Figure  D-80.  Data  flow  diagram  for  Process  Engagement  Message,  Receiving  Fire. 
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Uses  gun  target  line  (GTL)  to  determine  whether  intervening  terrain  provided  cover  at  time  of  impact 
Calculates  time  of  impact 

'  Compares  own  location  at  time  of  impact  to  location  of  the  impact,  using  a  CEP  formula,  determines 
whether  damaged  or  not 

Each  entity  must  “know”  its  own  vulnerability  to  types  of  ordnance  by  using  a  look-up  table,  i.e.,  a 
human  object  would  “look  up”  its  vulnerability  to  a  single  bullet  at  the  same  time  and  location  as  it 
was ...  perhaps  roll  a  die  to  see  if  it  was  “killed,”  wounded,  etc.  ^  a  tank  object  would  know  it  was 
impervious  to  a  single  bullet  or  other  small  arms  ordnance. 


Figure  D-81 .  Data  flow  diagram  for  Determine  Engagement  Results,  Receiving  Fire. 


Data  File  Data  File 


*  Light,  weather,  and  terrain  are  used  to  determine  if  perceptual 
results  can  be  calculated,  and  how  extensive.  If  point  of  impact 
can  be  observed,  true  BDA  is  sent.  If  not  observed  or  with  high 
obscuration  {smoke,  distance,  intervening  terrain),  BDA  are 
randomly  degraded. 

Figure  D-82.  Data  flow  diagram  for  Determine  Perceptual  Engagement  Results,  Receiving  Fire. 
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Figure  D-83.  Data  flow  diagram  for  Send  BDA  Message,  Receiving  Fire. 
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Figure  D-84.  Data  flow  diagram  for  Change  Location,  Receiving  Fire. 
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Figure  D-85.  State  diagram  for  the  active  radar. 


Figure  D-86.  Data  flow  diagram  for  the  Radar  Off  state. 


Figure  D-87.  Data  flow  diagram  for  the  Radar  Standby  state. 
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Figure  D-89.  State  diagram  for  the  active  sonar. 


Figure  D-90.  Data  flow  diagram  for  the  Sonar  Off  state. 
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Figure  D-91 .  Data  flow  diagram  for  the  Sonar  Standby  state. 


bounce  or  convergence  zone. 

Figure  D-92.  Data  flow  diagram  for  the  Sonar  Operate  state. 
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Active 

Viscom  (Visuai  Communications,  Signal  Light,  Laser) 


Figure  D-93.  State  diagram  for  the  active  viscom. 
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Figure  D-94.  Data  flow  diagram  for  the  Viscom  Off  state. 


Figure  D-95.  Data  flow  diagram  for  the  Viscom  Standby  state. 


Figure  D-96.  Data  flow  diagram  for  the  Viscom  Operate  state. 


Note:  Prior  to  proceeding  with  the  mission  the  pilot  must  confirm  that  the  described  systems  required  for 
the  mission  are  operating  properly  (i.e.,  if  AEW/C  -  Airborne  Early  Warning  and  Control  aircraft 
(E-2C/E-3C)  are  required  for  the  mission  they  must  be  operating). 


do:  elevation  data; 
deflection  data; 
aim  point; 

GTL*; 
firing  time; 
range; 

TOT**; 

prepare  engagement  message 
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APPENDIX  E:  GLOSSARY 


A2c2 

Army  Airspace  Command  and  Control 

AAW 

Anti-Aircraft  Warfare 

ABCCC 

Airborne  Battlefield  C^  Center 

ACC 

Air  Component  Commander 

ACINT 

Acoustic  Intelligence 

ADA 

Air  Defense  Artillery 

AFAC 

Airborne  Forward  Air  Controller 

AI 

Air  Interdiction 

ALCC 

Airlift  Control  Center 

ALCE 

Airlift  Control  Element 

AMW 

Amphbious  Warfare 

AO 

Area  of  Operation 

AOO 

Air  Operations  Orders 

APOD 

Airport  of  Debarkation 

ARFOR 

Army  Forces 

ARG 

Amphibious  Ready  Group 

AREA 

Advanced  Research  Projects  Agency  (DoD) 

ASOC 

Air  Support  Operations  Center 

ASUW 

Air  Support  Operations  Center 

ASW 

Anti-Surface  Warfare 

ATO 

Air  Tasking  Order 

ATP 

Ammunition  Transfer  Point 

AWACS 

Airborne  Warning  and  Control  System 

AWSIM 

Advanced  Weapon  System  Information  Management 

BCA 

Bomb  Damage  Assessment 

BCE 

Battlefield  Coordination  Element 

C2 

Command  and  Control 

C2RM 

Command  and  Control  Reference  Model 

C^I 

Command,  Control,  Communications  and  Intelligence 

C^I 

Command,  Control,  Communications,  Computers  and  Intelligence 

CA 

Counter  Air 

CAD 

Computer  Aided  Design 

CAM 

Computer  Aided  Manufacturing 

CAS 

Close  Air  Support 

CCIR 

Commander’s  Critical  Information  Requirements 

CCT 

Combat  Control  Element 

CECOM 

U.S.  Army  Communications/Electronics  Command 

CEP 

Circle  Error  of  Probability 

CEWI 

Combat  Electronic  Warfare  Intelligence 

CFA 

Covering  Force  Area 

CID 

Combat  Intelligence  Division 

CINC 

Commander-in-Chief 

CINCPACFLT 

Commander-in-Chief  U.S.  Pacific  Fleet 

CJTF 

Commander  Joint  Task  Force 

CLIPS 

C  Language  Production  System 
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CLOS 

Common  Lisp  Object  System 

CM 

Configuration  Management 

CMD  GP  MEB 

Commander  Group  Marine  Expeditionary  Brigade 

COA 

Course  of  Action 

COFM 

Correlation  of  Forces  and  Means 

COMCARGRU 

Commander  Carrier  Group 

COMINT 

Communications  Intelligence 

COMMZ 

Communications  Zone 

CONUS 

Continental  United  States 

CORBA 

Common  Object  Request  Broker  Architecture 

COTS 

Commercial  Off-the-Shelf 

CRC 

Control  and  Reporting  Center 

CRP 

Control  and  Reporting  Post 

CSR 

Controlled  Supply  Rates 

CVN 

Nuclear  Carrier 

CWM 

Composite  Warfare  Model 

DAS 

Defensive  Air  Support 

DEEM 

Dynamic  Environmental  Effects  Model 

DF 

Defense  Force 

DIS 

Distributed  Interactive  Simulation 

DISCOM 

Division  Support  Command 

DISUM 

Division  Summary 

DIVARTY 

Divisional  Artillery 

DMSO 

Defense  Modeling  and  Simulation  Office 

DoD 

Department  of  Defense 

DS 

Direct  Support 

DSI 

Defense  Simulation  Internet 

EA 

Engagement  Area 

ECM 

Electronic  Countermeasures 

ELINT 

Electronic  Intelligence 

EMCON 

Emissions  Control 

ENSCE 

Enemy  Situation  Correlation  Element 

ESM 

Electronic  Support  Measures 

EW 

Electronic  Warfare 

FAARP 

Forward  Area  Arming  and  Refueling  Points 

FAC 

Forward  Air  Controller 

FACP 

Forward  Air  Control  Post 

FASCAM 

Family  of  Scatterable  Mines 

FEBA 

Forward  Edge  of  Battle  Area 

FF 

Fast  Frigate  (USN  Ship  Designation) 

FFG 

Guided  Missile  Frigate  (USN  Ship  Designation) 

FLOT 

Front  Line  of  Troops 

FORSTAT 

Force  Status  Report 

FRAGO 

Fragmentary  Order 

FSB 

Forward  Support  Battalion 
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FSCL 

Fire  Support  Coordination  Line  (Army,  Air  Force) 

FSK 

Frequency  Shift  Keying 

CACC 

Ground  Attack  Control  Center 

GCI 

Ground  Control  Intercept 

GOTS 

Government  Off-the-Shelf 

GRREG 

Graves  Registration  Points 

GS 

General  Support 

GS/R 

General  Support/Receiving 

GSR 

General  Support  Reinforcing 

HCI 

Human-Computer  Interaction 

HF 

High  Frequency 

HHC 

Headquarters/Headquarters  Company 

HMH 

Marine  Heavy  Helicopter  Squadron 

HMLA 

Light  Attack  Helicopter  Squadron 

HN 

Medium  Helicopter  Squadron 

HN 

Host  Nation 

Hq 

Headquarters 

lAC 

Information  Analysis  Center 

IDL 

Interface  Definition  Language 

ffiW 

Intelligence  and  Electronic  Warfare 

IFV 

Infantry  Fighting  Vehicle 

IMINT 

Imagery  Intelligence 

INT 

Inteligence 

INTSUM 

Intelligence  Summary 

ISO  OSI 

International  Standards  Organization’s  Open  Systems  Interface 

JAAT 

Joint  Air  Attack  Team 

JCS 

Joint  Chiefs  of  Staff 

JFNCC 

Joint  Forces  Naval  Component  Command 

JOPES 

Joint  Operational  Planning  and  Execution  System 

JSIMS 

Joint  Simulation  System 

JTF 

Joint  Task  Force 

JTF-ATD 

Joint  Task  Force-Advanced  Technology  Demonstration 

JWID 

Joint  Warrior  Interoperability  Demonstration 

JWSOL 

Joint  Warfare  Simulation  Object  Library 

KADS 

Knowledge  Acquisition  and  Design  Structuring 

KRSL 

Knowledge  Representation  Specification  Language 

Lie 

Low-Intensity  Conflict 

LOG 

Lines  of  Communication 

LOSREP 

Line  of  Sight  Report 

LP 

Listening  Posts 

LRSU 

Long  Range  Surveillance  Units 

M&S 

Modeling  and  Simulation 

MALSFW 

Marine  Aviation  Logistics  Squadron  (Fixed  Wing) 
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MALSRW 

MARS 

MASINT 

MBA 

MEB 

METT-T 

MIJI 

MIW 

MODSIN 

MOS 

MP 

MWSSFW 

MRB 


Marine  Aviation  Logistics  Squadron  (Rotary  Wing) 

Multiwarfare  Assessment  and  Research  System 

Measurements  and  Signature  Intelligence 

Main  Battle  Area 

Marine  Expeditionary  Brigade 

Mission,  Enemy,  Troops,  Terrain,  and  Time 

Meaconing,  Intrusion,  Jamming  and  Interference 

Mine  Warfare 

A  programming  language 

Miltary  Operational  Specialty 

Military  Police 

Wing  Support  Squadron  Fixed  Wing 
Model  Request  Broker 


NALE 

NBC 

NCA 

NCCOSC 

NEO 

NETT 

NGFS 

NRaD 

NSS 

NSW 

NUDET 


Naval  and  Amphibious  Liaison  Element 
Nuclear/Biological/Chemical 
National  Command  Authority 

Naval  Command,  Control  and  Ocean  Surveillance  Center 
Non-Combatant  Evacuation  Operation 
New  Equipment  Training  Team 
Naval  Gun  Fire  Support 

Naval  Command,  Control  and  Ocean  Surveillance  Center,  RDT&E  Division 
Naval  Simulation  System 
Navy  Special  Warfare 
Nuclear  Detonation 


OAS 

OCOKA 

ODBMS 

OLE 

OMWG 

OO 

OOA 

OOD 

OP 

OPAREA 

OPLANS 

OPORD 

OPREP 

OPSEC 

ORB 

OT 


Offensive  Air  Support 

Observation  and  Fields  of  Fire,  Cover  and  Concealment,  Objectives, 
K— Key  Terrain,  A — Avenues  of  Approach 
Object  Oriented  Database  Management  System 
Object  Linked  Embedding 
Object  Management  Working  Group 
Object  Oriented 
Object  Oriented  Analysis 
Object  Oriented  Design 
Observation  Posts 
Operational  Area 
Operational  Plans 
Operational  Order 
Operational  Report 
Operations  Security 
Object  Request  Broker 
Object  Technology 


PA  Public  Affairs 

PIM  Position  of  Intended  Movement 

PIR  Priority  Information  Requirements 

PIREP  Pilot  Inflight  Report 
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POL 

PVO 

R 

RAD 

RCT 

RDT&E 

REINF 

RESA 

ROE 

RSR 

SAPOR 

SAM 

SCUDS 

SIGINT 

SIGSEC 

SITREP 

SLOC 

SME 

SOP 

SOP 

SPIREP 

SPOD 

SQT 

SSN 

STOW 

STW 

TACC 

TACOP 

TACP 

TACREP 

TACRON 

TAP 

TCP 

TCP/IP 

TESS 

T/0 

TOW 

TPFDL 

TRADOC 

u&s 

UHF 

UJTL 

USCENTCOM 

USMTF 

UTM 


Petroleum,  Oil,  and  Lubricants 
Operational  planning  process 

Reinforcing 

Rapid  Application  Development 
Regimental  Combat  Team 
Research,  Development,  Test  &  Evaluation 
Reinforced 

Research,  Evaluation  and  Systems  Analysis  Facility 
Rules  of  Engagement 
Required  Supply  Rates 

Semi-Automated  Forces 
Surface-to-Air  Missile 

Soviet  short  range  surface-to-surface  missiles 

Signals  Intelligence 

Signal  Security 

Situation  Report 

Sea  Lines  of  Communication 

Subject  Matter  Expert 

Special  Operating  Forces 

Standard  Operating  Procedure 

Special  Purpose  Intelligence  Report 

Seaport  of  Debarkation 

Skill  Qualification  Testing 

Submarine,  Nuclear 

Synthetic  Theater  of  War 

Strike  Warfare 

Tactical  Air  Control  Center 

Tactical  Air  Control  Post 

Tactical  Air  Control  Party 

Tactical  Report 

Tactical  Air  Control  Squadron 

Tactical  Air  Force 

Traffic  Control  Point 

Transport  Control  Protocol/Internet  Protocol 
Tactical  Environmental  Support  System 
Table  of  Organizations 

Tube  Launched,  Optically  Tracked,  Wire  Guided  (Missile) 
Time-Phased  Force  Deployment  List 
Training  and  Doctrine  Command 

Unified  and  Specified 

Ultra  High  Frequency 

Universal  Joint  Task  List 

U.S.  Central  Command 

United  States  Message  Text  Format 

Universal  Transverse  Mercator 
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v&v 

Verification  and  Validation 

VHP 

Very  High  Frequency 

VLF 

Very  Low  Frequency 

VM 

Marine  Aerial  Refueler  Transport  Squadron 

VMA 

Marine  Attack  Squadron 

VMFA 

Marine  Fighter  Attack  Squadron 

VMG 

Marine  Observation  Detachment 

VTDP 

Target  Vector  Designation  Points 

VV&A 

Verification,  Validation  and  Accreditation 

woe 

Wing  Operations  Center 

WWMCCS 

Worldwide  Military  Command  and  Control  System 
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